PHP数组新特性不破坏老代码运行，但影响可维护性与类型安全；只读数组禁止修改、严格类型暴露隐患、短数组语法提升推导精度，需渐进式采用而非强制升级。
PHP 数组新特性（尤其是 PHP 8.1 引入的 只读数组 和 PHP 8.2 的 只读类 支持，以及 PHP 8.3 对数组类型推导的增强）本身 不会破坏现有老代码的运行，但会显著影响代码的可维护性、类型安全性和未来升级路径。关键不在于“能不能跑”，而在于“要不要改”和“什么时候改”。
只读数组（readonly array）不兼容老代码的写法
PHP 8.1 加入了 readonly array 类型声明（需配合 readonly 属性使用），它禁止对数组内容做任何修改（如 $arr[] = ...、unset()、array_push() 等）。老代码中大量存在“先声明数组、再动态追加元素”的习惯写法，一旦你把某个属性改成 public readonly array $items = [];，所有后续的写操作都会触发 Fatal error。
- 老代码常见模式：
$this->data[] = $item;→ 在只读数组下直接报错 - 替代方案不是“去掉 readonly”，而是明确区分用途：用普通数组做可变容器，用只读数组做配置/常量数据（如
public readonly array $allowedTypes = ['jpg', 'png'];） - 升级建议：不要强行给所有数组加
readonly，优先在 DTO、配置类、返回值类型中引入，配合静态分析工具（如 PHPStan）识别误用
数组类型声明更严格，暴露老代码中的类型隐患
PHP 8.0+ 开始支持更精确的数组类型，如 string[]、array<int user></int>、list<string></string>。虽然老代码用 array 还能照常运行，但一旦你开始添加类型声明或启用严格类型检查（declare(strict_types=1);），很多隐式类型转换就会变成错误。
- 例如老代码中
function getName(array $user) { return $user['name'] ?? ''; }，若传入['name' => 123]，之前可能默默返回'123'；加上array{ name: string }后，PHPStan 或 Psalm 会立刻报错 - 函数参数从
array升级为array<string mixed></string>或更具体的形状数组时，调用方若传入键名不匹配的数组，IDE 和分析器会预警 - 建议分阶段推进：先用 PHPStan level 5 检查老项目，聚焦修复
array使用处的键缺失、类型不一致问题，再逐步细化类型注解
方括号语法（[]）不再是唯一选择，但老代码无需重写
PHP 5.4 引入的短数组语法 [] 已成事实标准，PHP 新版本并未废弃 array()。不过 PHP 8.3 增强了对 [] 的类型推导能力（尤其在泛型上下文中），而 array() 在某些复杂泛型场景下可能无法被准确推断。这不会导致老代码出错，但会影响 IDE 补全精度和类型分析深度。
立即学习“PHP免费学习笔记（深入）”；
-
$users = array_map(fn($u) => new User($u), array());→ PHPStan 可能无法推断$users是User[] -
$users = array_map(fn($u) => new User($u), []);→ 更大概率被正确推导为User[] - 这不是强制要求，但团队统一用
[]能提升静态分析效果，适合在新模块或重构时采用
新特性本身是渐进式演进，没有一刀切的破坏力。真正的影响来自你主动采用它们时，对老代码松散实践的反向约束——它逼你直面那些“能跑就行”的隐性假设。不升级没关系，但想用现代 PHP 写得更稳、更清晰，就得从数组这个最基础的数据结构开始重新审视。
