strict_types=1 对 PHP 数组合并的键类型无直接影响，仅约束函数参数类型检查；数组键强制转为 int 或 string 是 PHP 底层规则，与 strict 模式无关。
declare(strict_types=1); 对 PHP 8.0 合并数组（如 array_merge()、+、array_replace() 等）的键类型没有任何直接影响。
原因很明确：
-
strict_types=1只约束函数参数的类型检查行为，不干预数组底层结构、键的类型推导、或数组操作函数的内部逻辑； - PHP 数组的键天然只有两种合法类型：整型（int）和字符串（string），其他类型（如
float、bool、null、对象等）在作为键时会被强制转换——这是 PHP 语言层的硬性规则，与strict_types无关； - 所有数组合并函数（包括
array_merge()）都按 PHP 内置规则处理键，不会因开启严格模式而改变键的转换方式或报错。
常见键类型转换行为（strict_types 不改变这些）
当你用非标准类型作键时，PHP 总是按以下规则转成 int 或 string：
-
true→"1"（字符串） -
false→"0"（字符串） -
null→""（空字符串） -
3.7→3（整型，截断） -
[]（空数组）→ 触发Warning: Illegal offset type - 对象 → 触发
Fatal error: Object of class X could not be converted to string（若用于字符串上下文）
这些警告/错误在 strict_types=1 下也不会升级为 TypeError，因为它们属于“非法偏移量”语义错误，不是参数类型不匹配问题。
PHP 8.5.12
下载
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
立即学习“PHP免费学习笔记（深入）”；
strict_types 可能间接影响的场景（需注意）
虽然它不改键行为，但在你自己写的、带类型声明的数组处理函数中，strict_types=1 会影响你如何传参：
declare(strict_types=1);
function processKeys(array $data, string $prefix): array {
return array_map(fn($v) => $prefix . $v, $data);
}
// ✅ 正确：$data 是 array，$prefix 是 string
processKeys(['a', 'b'], 'item_');
// ❌ 报错：$prefix 是 int，但声明要求 string
// processKeys(['a'], 123); // TypeError: Argument 2 must be of type string但注意：这个错误发生在你调用 processKeys() 时，和 array_merge() 的键无关。
合并数组时真正要注意的键冲突问题
-
+运算符：保留左边数组的键，右边同名键被忽略； -
array_merge()：数字键重排，字符串键后者覆盖前者； - 键类型混用（如
'1'和1）会被视为不同键（因为一个是字符串，一个是整数），不会自动合并或覆盖——这容易引发逻辑疏漏，但仍是 PHP 原生行为，strict_types 不介入。
示例：
$a = [1 => 'x', '1' => 'y']; print_r($a); // 输出：Array ( [1] => x [1] => y ) → 实际只保留最后一个？不，PHP 中整数键 `1` 和字符串键 `'1'` 是两个独立键，但 var_dump 显示会“覆盖”视觉效果；真实结构可通过 `array_keys($a, null, true)` 区分。
总结关键点
-
strict_types=1不控制、不校验、不改变数组键的类型或转换逻辑； - 数组键的类型转换由 PHP 引擎底层决定，无论 strict 模式是否开启；
- 若你在合并前手动构造键（比如
$arr[(string)$id] = ...），那strict_types可能影响$id转换前的参数类型（例如string $id被误传int就会报错），但这属于函数入参检查，不是数组合并本身； - 真正要防范的是键类型混淆导致的数据覆盖或丢失，应统一使用
is_int()/is_string()显式判断，或用(string)/(int)主动转换，而非依赖隐式行为。
