PHP的json_encode()根据数组键是否为从0开始的连续非负整数决定输出JSON数组[]或对象{}；索引数组要求键全为连续整数，否则转为关联数组（JSON对象），影响前后端数据解析一致性。
索引数组和关联数组在 JSON 编码时行为完全不同
PHP 的 json_encode() 会根据数组“键的构成”自动决定输出 JSON 数组（[]）还是 JSON 对象（{}，即 JavaScript object），而不是看变量名或注释。
关键判断逻辑是：如果数组所有键都是从 0 开始的连续非负整数（允许跳过末尾，但不能缺中间），就转成 JSON 数组；否则一律转成 JSON 对象。
-
json_encode([1, 2, 3])→[1,2,3]（索引数组，连续整数键） -
json_encode(['a' => 1, 'b' => 2])→{"a":1,"b":2}（关联数组，字符串键） -
json_encode([1 => 'a', 2 => 'b'])→{"1":"a","2":"b"}（不是从 0 开始 → 当作关联数组） -
json_encode([0 => 'a', 2 => 'b'])→{"0":"a","2":"b"}（不连续 → 关联数组）
这个行为在前后端联调时极易踩坑：后端 PHP 返回一个看似“顺序”的数组，前端却收到 object，导致 .map() 报错。
is_array() 和 array_keys() 看不出区别，但 key 类型决定本质
is_array() 对两者都返回 true，var_dump() 显示格式不同只是表象。真正影响行为的是键的类型和生成方式。
立即学习“PHP免费学习笔记（深入）”；
- 索引数组的整数键可以是隐式生成（
$arr[] = 'x'）、显式指定（$arr[5] = 'x'），但只要全是 int 且“看起来像数组”，PHP 内部就按顺序结构优化 - 关联数组的键哪怕写成
'123'（字符串）或1.5（float，会被转成'1.5'），就立刻进入哈希路径，不再尝试维护数字顺序 -
array_keys($arr)返回的永远是字符串或整数混合数组，无法靠它反推“原数组类型”
别用 array_keys() 的返回值类型来判断数组类别——它只反映当前键的字面类型，不反映语义意图。
foreach 遍历行为一致，但 key 类型影响 isset() 和 [] 访问
无论索引还是关联数组，foreach ($arr as $k => $v) 都能正常工作，顺序也保持插入顺序（PHP 7.4+ 保证哈希表插入序）。
- 但
isset($arr[1])在[0=>'a', 2=>'b']中返回false，因为键1确实不存在；而isset($arr['1'])可能为true（若存在字符串键'1'） - 数字字符串键和整数键在 PHP 中不等价：
$arr[1]≠$arr['1']—— 前者查整数键，后者查字符串键 - 用
in_array()查值没问题，但用array_search()时要注意第三个参数$strict：默认松散比较，0 == '0'成立，可能误匹配
最常出问题的是把 API 返回的 JSON 对象（如 {"0":"a","1":"b"}）用 json_decode($json, true) 解出来，结果得到一个“键全为字符串的数组”，表面像索引数组，实际是关联数组。
性能差异微乎其微，但设计意图必须明确
底层都是 HashTable，增删改查时间复杂度都是均摊 O(1)，所谓“索引数组更快”是过时机理误解。现代 PHP（8.0+）对纯整数键做了额外优化，但差距在纳秒级，业务代码里根本测不出来。
- 真正该关心的是语义：你要表达的是「第 N 个元素」还是「名为 X 的字段」？前者用索引数组（如日志列表、选项列表），后者用关联数组（如用户资料、配置项）
- 混用会导致可读性崩塌：比如
['name' => 'Tom', 0 => 'admin']—— 这既不是纯索引也不是纯关联，count()返回 2，但array_values()会重排索引，array_keys()返回['name', 0]，极易引发逻辑错乱 - 函数如
array_merge()对索引数组会重排数字键，对关联数组则直接追加——传错类型，结果可能完全不是你想要的
PHP 不强制区分二者，所以最容易被忽略的点是：**你写的代码是否让后续维护者一眼看懂数据结构意图？** 键的类型选择，本质是接口契约的一部分。
