PHP数组设计不合理会导致维护困难、逻辑混乱和高风险改动；应统一结构、分离索引类型、用结构代替隐式约定、避免万能数组传参。
PHP 数组设计不合理，最直接的后果不是运行报错，而是让后续维护的人（可能是你自己半年后）反复翻代码、加注释、写临时转换逻辑，最终把简单需求拖成高风险改动。
嵌套过深且结构不一致
常见于从 API 或数据库拼装数据时，没做归一化处理。比如用户列表返回中，有的项带 profile 子数组，有的为空字符串或 null，有的干脆缺失该键；地址字段又分 addr、address_info、location 多种命名。这种“每条数据像一个小型 schema”的数组，会让 foreach 里堆满 isset()、empty()、array_key_exists() 判断。
建议：在数据组装层（如 Service 或 DTO 构建处）强制统一结构。用默认值填充可选字段，用固定键名，宁可存 null 也不留空字符串或缺键。例如统一用 address 键，内部始终是含 city、street、zip 的关联数组。
混合类型键名：数字索引 + 字符串键混用
比如一个配置数组既用 [0] => 'mysql'，又用 ['driver'] => 'mysql'，还夹着 [1] => ['host' => '...']。这种写法看似灵活，实则破坏遍历预期——foreach 无法安全假设 $v 是字符串还是数组；json_encode 后变成对象还是数组也难预料；更别说 array_values() 或 array_keys() 会意外打乱语义。
立即学习“PHP免费学习笔记（深入）”；
建议：明确用途再选结构。纯列表用数字索引（如 $roles = ['admin', 'editor']）；属性集合用字符串键（如 $config = ['host' => '127.0.0.1', 'port' => 3306]）；避免在同一层数组中混用。必要时拆成两个独立变量。
过度依赖“魔法键名”和隐式约定
比如所有接口返回都约定 data 包业务数据、code 表状态、msg 是提示——这本身没问题。但若进一步要求：当 code === 0 时 data 是数组，code === 1 时 data 是字符串，code === -1 时 data 不存在……这类靠文档而非结构约束的约定，极易在新增分支逻辑时被忽略。
建议：用结构代替注释。返回统一包装为标准响应类实例，或至少用严格数组 shape：['code' => int, 'msg' => string, 'data' => mixed]，并在关键入口做 type assertion（如 assert(is_array($res) && isset($res['code']))）。配合 PHP 8.0+ 的联合类型与数组解包，能显著降低误读概率。
未封装可变逻辑，把数组当万能容器传参
函数签名形如 function handleOrder(array $input)，而 $input 实际承载订单信息、支付参数、通知配置、甚至调试开关——每次调用都要看调用方怎么塞、被调用方怎么取。改一个字段名，要 grep 全局十多个地方；加一个新参数，得同步更新所有调用点。
建议：用具名参数替代“大数组”。PHP 8.0 支持命名参数，更早版本可用数组解构或专用参数对象。例如：
processOrder(id: $id, amount: $amt, notify: true)
或封装为 new OrderRequest($id, $amt)->withNotify(true)。数组只用于真正动态、未知结构的场景（如原始表单 POST 数据）。
