php数组在分层架构中无固定职责，其使用须契合各层契约：view层只读渲染、controller层轻量协调并转换数据、service层内部临时使用但对外返回结构化结果、repository层限制数组作用域、配置层仅作声明用途。
PHP 数组本身没有架构职责，它只是语言内置的数据结构。在分层架构（如 MVC、三层架构）中，数组的使用方式和出现位置，取决于所在层的职责边界——关键不在“数组能做什么”，而在“哪一层该用数组、怎么用才不破坏分层契约”。
表现层（View）：安全、只读地渲染数组
View 层接收控制器传来的数据（常为关联数组或对象），仅用于模板渲染，不做修改、不参与业务判断。
- 避免在模板中对数组做 filter、sort、merge 等逻辑操作；应由 Controller 或 Service 预处理好
- 用
isset()或array_key_exists()检查键存在性，防止未定义索引警告 - 敏感数据（如用户密码、token）绝不能以原始数组形式直接
print_r或var_dump输出
控制层（Controller）：轻量协调，谨慎传递数组
Controller 是各层之间的“粘合剂”，它可接收请求参数（$_GET/$_POST 原生数组），但应尽快转换为领域对象或验证后的结构化数据，而非长期持有或层层透传原始数组。
- 请求参数数组需经验证与过滤（如用
filter_input_array()或表单请求类）再交予 Service - 不把数据库查询结果数组（如 PDO::FETCH_ASSOC）直接返回给 View；应封装为 DTO 或 ViewModel
- 避免在 Controller 中拼装多维嵌套数组表示业务关系（例如
['user'=>['posts'=>[...]]）；这属于领域建模范畴，应下沉到 Domain 或 Service
服务/领域层（Service / Domain）：用数组表达临时结构，不暴露实现细节
Service 层可内部使用数组组织中间计算结果（如聚合统计、缓存键组装、批量 ID 列表），但对外接口应保持契约清晰——返回对象、标准 DTO 或明确语义的数组（如 ['success'=>true, 'data'=>...]），而非裸数组。
立即学习“PHP免费学习笔记（深入）”；
- 领域模型（Entity/VO）优先用对象而非数组承载状态；数组仅用于跨层序列化（如 JSON 返回）、缓存值或配置项
- 若必须返回数组（如 API 接口），应通过专用的响应构造器（如
ApiResponse::success($data)）统一格式，避免散落各处的return ['code'=>0, 'msg'=>'ok', ...] - 数据库访问层（Repository）返回数组时，应明确是“原始记录数组”还是“投影数组”，并限制其作用域（例如仅供 Service 内部使用，不向 Controller 暴露 PDO 关联数组）
配置与基础设施层：数组作为声明式配置载体
框架配置、路由定义、依赖注入映射等场景，数组因简洁灵活被广泛采用（如 Laravel 的 routes/web.php、Symfony 的 services.yaml 对应 PHP 数组写法）。此时数组是“声明”而非“数据”，职责是描述行为，不参与运行时业务流程。
- 配置数组应不可变（如定义在
return [...];的文件中），避免运行时修改 - 避免在配置数组中写业务逻辑（如匿名函数、动态调用），会模糊配置与代码边界
- 大型项目建议将复杂配置转为独立配置类或 YAML/JSON 文件，由配置管理器加载为结构化对象，降低数组嵌套维护成本
数组不是分层架构的参与者，而是各层在履行自身职责时选择的工具。用得好，它轻快透明；用得随意，就会成为跨层污染、类型模糊和调试噩梦的入口。守住每层的输入/输出契约，比纠结“数组该在哪用”更重要。
