php会将形似数字的字符串键（如"1"、"01"）强制转为整数导致键覆盖；需用array_keys($arr, null, true)查真实键类型，对用户输入应立即过滤而非延迟转换。
字符串键名被自动转成整数导致覆盖
PHP 会把看起来像数字的字符串键（比如 "1"、"01"、"1.5"、"true"）强制转为整数或浮点数，再用作数组键。结果就是多个不同写法的键最终都变成同一个整数键，后赋值的直接覆盖前面的。
常见错误现象：var_dump(["1" => "a", 1 => "b", "1.0" => "c"]) 输出只有 [1 => "c"]；["01" => "x", "1" => "y"] 也只剩一个元素。
- 用
array_keys($arr, null, true)配合array_values()拆开键值，避免依赖键名语义 - 如果必须保留原始字符串键（如数据库字段名、API响应字段），就别让它进数组键——改用嵌套结构，例如
[["key" => "01", "value" => "x"], ["key" => "1", "value" => "y"]] - 调试时用
var_dump(array_keys($arr, null, true))查看真实键类型，true表示严格比较，能暴露字符串键是否已被转义
isset($arr['0']) 和 isset($arr[0]) 实际是同一回事
PHP 在底层对数组索引做松散比较：只要字符串内容能解析为整数，就会被当作数字索引处理。所以 isset($arr['0']) 和 isset($arr[0]) 完全等价，且都可能触发隐式转换，带来性能损耗和逻辑歧义。
使用场景：读取用户传参（如 $_GET['id']）、解析 JSON 后的关联数组、处理 CSV 映射列名时，容易误以为 '0' 是独立键。
- 统一用整数索引访问已知为数字位置的数据（如
$row[0]） - 若需区分字符串键与数字键，改用
array_key_exists('0', $arr)——它不触发类型转换，但注意它只查键是否存在，不判断值是否为null - 对用户输入的键名，先用
is_string($key) && ctype_digit($key)判断是否为纯数字字符串，再决定是否 cast 成 int
foreach 中用 & 引用修改后忘记 unset 导致残留引用
这是个经典陷阱：用 foreach($arr as &$v) 修改数组后，如果不显式 unset($v)，那个引用变量会持续绑定到最后一个元素，下次循环或后续代码中修改 $v 就会意外改掉原数组。
错误示例：$arr = [1,2,3]; foreach($arr as &$v) { $v *= 2; } $v = 999; var_dump($arr); 输出 [2,4,999]，第三个值被篡改。
- 每次用引用 foreach 后，紧跟一句
unset($v)，哪怕你确定后面没代码 - 更安全的做法是避免引用，改用键值遍历：
foreach($arr as $k => $v) { $arr[$k] = $v * 2; } - 如果数组很大且要频繁修改，考虑用
array_map()或array_walk()替代，它们天然隔离作用域
json_encode 的 JSON_NUMERIC_CHECK 不等于类型安全
JSON_NUMERIC_CHECK 看似能“修复”字符串数字，但它只是在编码时做一次模式匹配转换，不改变原始 PHP 变量类型。这意味着你在 PHP 层仍用字符串做计算，仅 JSON 输出好看而已。
后果：用 "123" 和 123 做 in_array()、== 比较，或参与算术运算，依然会触发隐式转换，结果不可控。
- 真正需要数值语义的地方，必须提前转换：
$id = filter_var($_GET['id'], FILTER_VALIDATE_INT) !== false ? (int)$_GET['id'] : null; - 不要依赖
JSON_NUMERIC_CHECK来掩盖数据清洗缺失；它适合前端展示层补救，不适合业务逻辑层 - 配合
declare(strict_types=1)+ 类型声明函数（如function calc(int $a, int $b): int）才能从源头堵住字符串乱入
实际项目里最常被忽略的，不是怎么转，而是在哪一层转——用户输入进来立刻过滤，还是等进 SQL 查询前才 cast？前者防错，后者埋雷。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
