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，影响生产环境。

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