array_key_exists 更可靠，因它严格区分“键存在但值为 null”和“键不存在”，而 isset 两者均返回 false；参数顺序为 key 在前、array 在后；仅支持一维数组键检查，不适用于对象属性。
array_key_exists 为什么比 isset 更可靠
检查键是否存在时，array_key_exists 明确区分“键存在但值为 null”和“键根本不存在”，而 isset 对这两种情况都返回 false。如果你的业务逻辑依赖于“键是否被声明过”，比如配置数组中显式设为 null 表示禁用某功能，那必须用 array_key_exists。
常见错误现象：isset($arr['foo']) 返回 false，你以为键没了，其实它在，只是值是 null —— 这会导致配置跳过、条件误判。
-
array_key_exists检查的是键名本身，不关心值类型或是否为null -
isset实际是“键存在且值不为null”的简写，本质是类型安全判断 - 性能上，两者差异极小，PHP 7+ 都是 O(1)，别为这点开销换逻辑
array_key_exists 的参数顺序不能反
函数签名是 array_key_exists($key, $array)，第一个参数是键（字符串或整数），第二个才是数组。顺序反了会触发警告甚至致命错误——PHP 不会自动类型推断纠正这个错。
典型翻车场景：从 JavaScript 或 Python 转过来的人习惯“in”操作符写法（如 'key' in obj），下意识写成 array_key_exists($arr, 'key')，结果报 Warning: array_key_exists() expects parameter 2 to be array, string given。
立即学习“PHP免费学习笔记（深入）”；
- 永远记住：键在前，数组在后
- IDE 通常能提示参数类型，但别依赖——加个注释或用 PHPStan 等工具做静态检查更稳妥
- 如果键来自用户输入（比如
$_GET['field']），先校验非空再传入，避免传入null或数字 0 导致意外行为
检查嵌套数组的键要用递归或路径拆解
array_key_exists 只查一级键，对 $arr['user']['profile']['avatar'] 这种路径无能为力。直接写 array_key_exists('avatar', $arr) 肯定返回 false，因为顶层根本没有 avatar 这个键。
真实需求常是：“这个深层键到底存不存在？”而不是“我手动展开三层再分别检查”。这时候要么手写递归函数，要么用现成路径解析方式。
- 简单场景可用
isset($arr['user']['profile']['avatar'])，但它依然受null值干扰 - 要兼顾
null和存在性，得逐层调用array_key_exists，比如先array_key_exists('user', $arr)，再array_key_exists('profile', $arr['user'])……容易写漏 - 更稳的做法是封装一个
array_key_exists_path($path, $array)，把'user.profile.avatar'拆成数组再遍历，避免重复逻辑
array_key_exists 在对象属性上完全无效
它只认数组，对 stdClass、自定义类实例、ArrayObject 都不适用。有人试过 array_key_exists('prop', $obj)，结果永远是 false，哪怕 $obj->prop 确实存在。
这是因为 PHP 的“数组”和“对象”在底层结构上完全不同，array_key_exists 的实现只走哈希表查找路径，不触发对象的魔术方法（如 __isset）。
- 检查对象属性是否存在，用
property_exists($obj, 'prop')（无视访问控制）或isset($obj->prop)（受private/protected影响） - 如果对象实现了
ArrayAccess，想模拟数组行为，仍需自己实现offsetExists方法，array_key_exists不会自动代理过去 - 混用数组和对象时（比如 JSON 解码后不确定是数组还是对象），先用
is_array()判定类型，再选对应检查方式
最易被忽略的一点：当数组键是数字字符串（如 '123'）时，array_key_exists 严格按字符串匹配，不会自动转成整型；而 isset($arr[123]) 却会把数字索引当作整数处理——这种隐式类型转换差异，在动态键名场景下很容易埋雷。
