PHP数组不应承担领域逻辑，仅宜作DTO或临时数据结构；需通过类型声明、校验及适时升级为值对象/实体类来保障可靠性，避免extract/compact等模糊语义的操作。
PHP 数组本身不是领域模型，但常被用作领域对象的轻量载体或临时数据结构。关键在于避免让数组承担本该由明确类定义的职责——比如业务规则、状态约束或行为逻辑。
用数组传递数据，不用数组封装领域逻辑
在服务层或应用层，数组适合做 DTO（数据传输对象）或参数包，例如从请求中提取的原始字段：
- 接收表单数据时用
$_POST或 JSON 解析后的关联数组，但应尽快映射为领域对象 - 调用第三方 API 返回的数组，可封装成
ApiResponse::fromArray()方法，而不是直接在业务逻辑里遍历$data['user']['profile']['age'] - 不要在数组里存方法引用、闭包或对象实例——这会让语义模糊且难以测试
配合类型声明和验证，弥补数组的弱约束
PHP 数组不带类型信息，容易引发运行时错误。可通过以下方式增强可靠性：
- 用 PHP 8+ 的联合类型和数组形状（如
array{username: string, age: int}）在函数签名中标注期望结构 - 在构造领域对象时校验数组键是否存在、类型是否匹配，例如：
if (!isset($data['email']) || !filter_var($data['email'], FILTER_VALIDATE_EMAIL)) { throw new InvalidEmailException(); } - 使用
array_key_exists()而非isset()判断可为null的字段
适时升级为值对象或实体类
当数组开始重复出现在多个地方、出现条件判断或计算逻辑时，就是重构信号：
立即学习“PHP免费学习笔记（深入）”；
- 地址信息（
['street', 'city', 'postal_code']）→ 提取为Address值对象，带isValid()和formatForMail() - 订单行项目（
['product_id', 'quantity', 'unit_price']）→ 封装为OrderItem实体，含总价计算、库存检查等行为 - 避免“数组嵌套数组”表示复杂关系，改用集合类（如
ProductCollection）管理多个对象
谨慎使用 extract() 和 compact()
这两个函数看似方便，实则隐藏了变量来源和结构依赖：
-
extract($data)会把数组键变成局部变量，破坏作用域清晰性，也难追踪哪些字段被用了 -
compact('name', 'email')依赖变量名与键名一致，在重构时易出错；建议显式构造：['name' => $this->name, 'email' => $this->email] - 若必须用，仅限模板渲染等纯展示层，且确保输入已过滤和标准化
数组是 PHP 的基础工具，但在领域建模中，它该是过渡材料，不是承重墙。清晰的边界、及时的抽象、克制的便利性，才能让模型既灵活又可靠。
