in_array()时间复杂度为O(n)，底层线性扫描，不建哈希索引；查键存在应选isset()或array_key_exists()（O(1)），高频查值可预建array_flip()反向映射。
in_array() 查大数据量数组时实际是 O(n) 时间复杂度
in_array() 不管 PHP 版本多新，底层仍是线性扫描——它不会自动建哈希索引。哪怕你查的是 ['id' => 123, 'name' => 'foo'] 这种关联数组，in_array(123, $arr) 仍要逐个比对值，无法利用键做跳转。实测在 10 万元素数组中查找末尾值，平均耗时 3–5ms（PHP 8.3，OPcache 开启），且随数据量几乎线性增长。
常见误判点：in_array() 看似“内置函数就该快”，但它不等价于“哈希查找”。它和手写 foreach 在最坏情况下的时间复杂度一致，只是 C 层实现略少开销，但差距微乎其微。
查键存在性别用 in_array()，改用 isset() 或 array_key_exists()
如果你真正想确认的是“某个键是否存在”，比如判断 $user['email'] 是否被设置，in_array('email', array_keys($user)) 是典型错误写法：先调用 array_keys() 生成新数组（内存+时间双开销），再线性扫一遍——两重 O(n)。
正确做法是直接用 isset($user['email'])（快、支持短路、不报 notice）或 array_key_exists('email', $user)（能捕获 null 值）。这两个操作都是 O(1)，无论数组多大，耗时基本稳定在 0.001ms 级别。
立即学习“PHP免费学习笔记（深入）”；
注意区别：
-
isset()对null键返回false -
array_key_exists()对null键返回true - 两者都不触发
__isset()魔术方法，纯原生键查
真要高频查值？提前用 array_flip() 建反向映射
当业务确实需要“根据值反查键”且频次高（如权限码转描述、状态 ID 转中文名），别每次调 in_array() 或 array_search()，而是初始化阶段一次性翻转：
$statusMap = ['active' => 1, 'pending' => 2, 'disabled' => 3]; $lookup = array_flip($statusMap); // ['1' => 'active', '2' => 'pending', ...] // 后续查：isset($lookup[$id]) ? $lookup[$id] : null;
这个 $lookup 数组的键就是原值，查起来就是 O(1)。代价是内存翻倍（小数组可忽略），且只适用于值唯一、可作为字符串键的场景（数字/字符串值安全，对象或数组会报错）。
别在循环里反复 array_flip()——那比 in_array() 还慢。
array_search() 和 in_array() 性能几乎没差别，但语义不同
两者底层共享大部分逻辑，PHP 8.3 中实测百万级数组下，耗时差异通常小于 0.1ms。选哪个取决于你要什么：
- 只关心“在不在” → 用
in_array()，返回布尔值，语义干净 - 需要“在哪儿”或后续要用键做其他操作 → 用
array_search()，返回键名（或false） - 查不到时都返回
false，但in_array()的false易被当成 0 或空字符串误判，记得用严格比较=== false
真正卡性能的地方从来不是函数选错，而是没意识到：查键和查值是两类问题，不能混用同一套工具。数据量一大，isset() 和 in_array() 的耗时差会从纳秒级拉开到毫秒级——而这点延迟，在 API 关键路径上足够让 P95 响应时间翻倍。
