优先使用 === 避免类型转换陷阱：== 会强制类型转换导致意外结果，如 "0" == false 为 true；=== 要求值与类型均一致；数组比较时 == 忽略键序而 === 要求键序相同；in_array() 等函数需显式启用 strict 模式。
用 == 还是 ===？类型转换是最大陷阱
PHP 的 == 会强制类型转换后再比较，=== 则要求值和类型都一致。很多“明明相等却返回 false”的问题，根源就在这儿。
常见错误现象："0" == false 返回 true，0 == "0" 也返回 true，但 "0" === false 是 false，0 === "0" 也是 false。
- 字符串
"0"、空字符串""、整数0、浮点数0.0、null、false在松散比较中常被混为一谈 - 用户输入（如表单）默认是字符串，直接用
==和整数比较极易出错 - 数据库查出的字段如果是
INT但 PHP 接收为字符串（比如 PDO 默认），==可能掩盖类型不一致问题
strcmp() 和 strcasecmp() 适合字符串比大小
当你要判断两个字符串谁大谁小（比如排序、字典序校验），别用 == 或 === —— 它们只返回布尔值，没法告诉你顺序关系。
strcmp() 区分大小写，strcasecmp() 不区分。它们返回整数：0 表示相等，负数表示第一个参数小，正数表示第一个参数大。
立即学习“PHP免费学习笔记（深入）”；
-
strcmp("apple", "banana")返回负数，strcmp("zebra", "apple")返回正数 - 注意：传入
null或非字符串类型会触发警告，建议先用is_string()防御 - 性能上，
strcmp()比==略慢，但差异微乎其微；真正影响性能的是反复调用——比如在循环里做大量字符串比较，可考虑提前归一化
数组比较不能只看 ==，键名和顺序都算数
PHP 数组用 == 比较时，只要键值对相同就认为相等，不检查顺序；而 === 还要求键的顺序完全一致。
常见错误现象：["a" => 1, "b" => 2] == ["b" => 2, "a" => 1] 是 true，但 === 是 false；更隐蔽的是，[1, 2] == [0 => 1, 1 => 2] 成立，但 [1, 2] == [1 => 2, 0 => 1] 就不成立（因为键顺序变了）。
- 如果业务逻辑依赖键的顺序（比如 POST 参数解析、配置合并），必须用
=== - 想忽略顺序只看内容是否一致，得自己写遍历或用
array_diff_assoc()+array_diff_assoc()双向检查 - 嵌套数组、对象、资源无法用
==或===安全比较，会静默失败或报错
用 in_array() 查元素时记得开 strict 开关
in_array() 默认是松散比较，跟 == 一样会类型转换，这是线上 bug 高发区。
比如 in_array("1", [0, 1, 2]) 返回 true（因为 "1" == 1），但你本意可能是找字符串 "1"，结果误匹配了整数 1。
- 务必显式传第三个参数
true：in_array("1", [0, 1, 2], true)才严格匹配类型 - 如果数组里混了不同类型的值（比如 API 返回的 JSON 解析结果），不开
strict几乎必然出错 - 性能上，开启
strict略快一点（跳过类型转换），但主要收益是语义清晰、行为可预测
类型隐式转换在 PHP 里不是边缘情况，而是日常。哪怕写个 if ($id == 1)，也要心里清楚 $id 到底是 int 还是 string —— 这个判断点，往往就在 var_dump 后多看一眼类型，而不是靠猜。
