array_search 默认松散比较导致类型隐式转换，易误匹配；必须启用 strict=true 并用 !== false 判断返回值，否则 0 与 false 混淆引发逻辑错误。
绝大多数 PHP 数组查找逻辑错误，根源不在写法，而在没意识到 in_array 和 array_search 默认是松散比较（==）——它会把 '1' 当成 1，把 '' 当成 0，甚至把 'hello' 当成 true。
in_array 为什么返回 true 却找不到你要的值？
这是最常被忽略的类型陷阱。默认行为下，in_array 不检查类型，只看“转换后是否相等”。比如：
-
in_array('1', [1, 2, 3])返回true（字符串'1'被转成整数1） -
in_array(0, ['', false, null])也返回true（空字符串、false、null全部被当成0） - 更隐蔽的是：
in_array('hello', [0, false, null])居然也返回true，因为'hello'转布尔为true，而true == 0是false，但true == false也是false……等等，不对 —— 实际上这里触发的是'hello'被转为整数时失败，结果是0，所以匹配了数组里的0。
解决办法只有一个：显式传入第三个参数 true，启用严格模式：in_array('1', [1, 2, 3], true) → false。
array_search 返回 false 却误判为 0？
array_search 找不到时返回布尔值 false，但它的返回值可能是整数 0（比如第一个元素就匹配），而 PHP 松散比较中 0 == false 成立。这就导致：
立即学习“PHP免费学习笔记（深入）”；
-
if (array_search('a', ['a', 'b'])) { ... }会进分支（因为返回0，被当成真值） -
if (array_search('x', ['a', 'b'])) { ... }也会进分支（因为返回false，但在 if 中被当成假值？不，等等 —— 实际上false在 if 中是假值，不会进；但问题出在你用==判断时：array_search(...) == false对0和false都成立）
正确判断方式永远是：if ($key !== false)，用全等运算符。同时，别忘了加 true 启用严格搜索，否则键可能找错。
该用 array_key_exists 还是 isset 判断键存在？
如果目标是“这个键是否存在”，而不是“这个键对应的值是否为真”，那就不能用 isset()：
$arr = ['name' => 'Alice', 'age' => null];-
isset($arr['age'])返回false（因为值是null） -
array_key_exists('age', $arr)返回true（键确实存在）
同理，in_array 查的是值，array_key_exists 查的是键 —— 两者完全不是一回事，混用必然出错。查键存在性，无条件选 array_key_exists。
大数组里反复调用 array_search 性能崩了怎么办？
array_search 是 O(n) 线性扫描，对 10 万条数据查 100 次，就是百万级比较。这时候别硬扛：
- 如果数组内容固定（如状态码映射表），提前反转成键值对：
$lookup = array_flip($statusList)，之后用isset($lookup[$needle])就是 O(1) - 如果数组动态但查询频繁，考虑用 SplFixedArray 或缓存搜索结果（尤其当
$needle有重复） - 别为了“看起来简洁”在循环里反复调用
array_search，先抽出来做一次索引
真正容易被忽略的点是：strict 参数不是“可选优化”，而是“语义必需”——当你在处理用户输入、API 响应或任何可能混入字符串数字的场景时，不加 true 就等于默认接受类型污染。这不是 bug 修复，是契约声明。
