in_array() 默认松散比较易致类型误匹配，必须显式设 strict=true 才能确保值与类型双重校验；混用类型、用户输入、前导零字符串等场景不加 strict 必踩坑，且 strict 无性能损耗。
in_array() 不加 strict 会自动类型转换
PHP 的 in_array() 默认使用松散比较（==），遇到类型不一致时会尝试隐式转换。比如字符串 '0123' 和整数 123 在非严格模式下可能被判定为相等；更危险的是，in_array(0, ['s', 'ss']) 竟然返回 true——因为 PHP 把字符串 's' 转成数字后是 0，然后 0 == 0 成立。
- 字符串
'0'、''、'false'等都可能被转为0 - 数字
0可能匹配到空数组、false、null（在某些旧版本中） - PHP 8.0.0 之前，
in_array('0', [0])和in_array(0, ['0'])都返回true，但语义完全错位
strict = true 才真正做“值 + 类型”双重校验
设为 true 后，in_array() 内部等效于用 === 逐个比对，杜绝类型擦除带来的歧义。这是唯一能保证“你搜什么，就只匹配那个东西”的方式。
-
in_array('123', [123], true)→false（字符串 ≠ 整数） -
in_array('0123', ['0123'], true)→true（类型和值都一致） -
in_array(0.0, [0], true)→false（float ≠ int） - 前导零字符串如
'007'不再意外匹配整数7
哪些场景不加 strict 必踩坑
只要数组里混了多种类型，或者你不确定输入来源的类型（比如来自 $_GET、JSON 解码、数据库字段），就不该依赖默认行为。
- 用户 ID 是字符串但数据库查出来是整数（尤其 MySQL
INT字段） - 配置项开关值为
'on'/'off'，但误传了1/0 - 处理带前导零的编码（如商品编号
'000123'、身份证号片段） - 单元测试中用 mock 数据验证存在性，类型稍有偏差就通过不了
性能和兼容性其实没代价
加 strict = true 不影响性能——PHP 底层只是把松散比较换成严格比较，无额外循环或拷贝。而且从 PHP 4.2 就支持该参数，所有现代版本（包括 PHP 8.x）行为一致。
立即学习“PHP免费学习笔记（深入）”；
- 别信“strict 慢”的传言：差异在纳秒级，远低于一次数组遍历开销
- 省略第三个参数不是“省事”，是把类型不确定性留给运行时猜
- 团队协作时，显式写
true比靠文档或注释说明“这里要严格”可靠得多
in_array() 后面那个 true 不该省。类型模糊带来的调试成本，远高于多敲三个字符。 
