PHP 7.0到8.3定义空数组的语法糖与底层原理解析

先给出明确结论：在 PHP 7.0 至 8.3 的十余个版本迭代中，定义空数组的方式并未引入任何新玩法。始终只有两种写法——[] 与 array()，且二者完全等价。说白了，这并非新特性，自 PHP 5.4 起就已投入使用，历经多次大版本更新，始终保持兼容、性能一致、语义未变。

[] 是短数组语法，本质为 array() 的语法糖

为何称 [] 为语法糖？因为它不改变底层运作机制，纯粹是为了简化书写。当你写下 []，解析器在词法分析阶段会自动将其转换为 array() 的内部表示，运行时生成的对象完全一致：

• 两者均返回真实的 array 类型，is_array([]) === true，count([]) === 0
• 嵌套场景下更直观：[['a'], []] 比 array(array('a'), array()) 可读性高得多
• 性能毫无差别——底层调用的是同一组 Zend 引擎数组构造函数，不会更快也不会更慢

array() 并非过时写法，而是显式语义的载体

别误以为 array() 已经落后。它既未被废弃，在 PHP 8.3 中也未标记为 deprecated。它保留了明确的“构造意图”以及良好的向后兼容价值：

• 若你的项目仍需支持 PHP 5.3 或某些特殊的旧环境，array() 是唯一稳妥的选择。
• 部分老旧的静态分析工具（例如特定版本的 PHP_CodeSniffer 配合 PSR-2 规范），对 [] 的类型推导不如 array() 那般顺畅。
• 团队规范若强调“显式优于隐式”，那么使用 array() 反而能增强代码的可维护性，尤其在教学和跨语言协作的场景中。

因此，它算不上过时，更像是一种“经典但可靠”的编程风格。

真正影响落地实践的不是语法，而是类型系统的演进

从 PHP 7.4 到 8.3，空数组怎样使用才最安全，关注点早已从“怎么写”转移到“在哪里写、如何约束”。

• 类属性声明时，必须采用 private array $items = [];——若写成 private array $items = array();，会直接触发语法错误，没有商量余地。
• ?array 是联合类型的语法糖（等价于 array|null），它只是放宽了类型契约，并非创建空数组的手段。声明 ?array 后，仍需自行完成初始化。
• PHP 8.1+ 对未防御的深层数组访问（比如 $cfg['db']['host']）会抛出明确的错误，这倒逼开发者主动使用 $cfg['db'] ?? [] 来初始化中间层，否则代码就会出问题。

也就是说，真正的风险不在于 [] 与 array() 的二选一，而在于类型系统对你如何书写空数组提出了新的约束条件。

自动化检查应聚焦上下文风险，而非语法本身

工具链完全不必纠结于 [] 还是 array()。真正值得捕捉的是以下三类问题：

• 动态属性赋值：例如 $obj->data = []; 但类中并未声明 public array $data。这会导致动态属性废弃警告。
• 类型契约错配：函数签名写了 function foo(array $x)，却传入 null 或一个字符串——类型检查会直接报错。
• 非安全访问：未使用 ?? [] 或 isset() 进行防御，就执行深层键访问，PHP 8.1+ 会抛出 Warning: Undefined array key，生产环境会直接出问题。

将注意力放在这些上下文风险上，远比争论两个等价的语法哪种更好更有实际价值。