先给出明确结论：在 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，生产环境会直接出问题。
将注意力放在这些上下文风险上，远比争论两个等价的语法哪种更好更有实际价值。
