php数组作返回值需明确结构、用关联键、避免魔法索引；优先返回结构完整带默认值的数组，必要时转dto；禁用list解构，保持向后兼容。
PHP 中把数组作为函数返回值很常见，但设计不当容易引发可读性差、类型模糊、维护困难等问题。关键不是“能不能用数组”，而是“怎么用得清晰、安全、可持续”。
明确数组结构，避免“魔法索引”
直接返回 ['name' => 'Tom', 'age' => 25] 没问题，但若返回 [0 => 'Tom', 1 => 25, 2 => 'admin']，调用方必须靠文档或猜测理解每个位置的含义，极易出错。
- 始终使用关联键（
array或[]的键名形式），禁用纯数字索引表达业务语义 - 键名要具名、一致、小写+下划线（如
user_id而非userID或UID） - 若结构较复杂，考虑用常量或配置数组提前定义键名，便于复用和校验
约定返回格式，减少空值歧义
函数可能查不到数据，此时返回空数组 []、null、还是带默认键的数组（如 ['name' => '', 'age' => 0]）？不同选择对调用方处理逻辑影响很大。
- 优先返回结构完整但值为空/默认的数组（例如
['id' => 0, 'name' => '', 'created_at' => null]），降低调用方判空负担 - 若业务上“无结果”与“有结果但字段为空”语义不同，应明确区分：前者返回
null，后者返回带空值的数组 - 避免混合策略——同一函数不要有时返
null，有时返空数组
必要时封装为对象，别让数组承担太多职责
当数组开始包含方法逻辑（如 ->toArray()）、需要验证规则、或频繁被多处以相同方式解析时，说明它已超出“数据容器”的范畴。
立即学习“PHP免费学习笔记（深入）”；
- 字段超过 4–5 个，或存在嵌套结构（如
'profile' => ['city' => 'Beijing', 'tags' => [...]]），建议转为 Value Object 或 DTO 类 - 使用 PHP 8.0+ 的联合类型 + 返回类型声明（如
function getUser(): array|false）能提升 IDE 支持和静态分析能力，但不如: UserDto清晰 - 若暂不升级或项目约束强，可用数组+PHPDoc 补充类型提示，例如：
/** @return array{user_id: int, username: string, is_active: bool} */
兼容性与演进：预留扩展空间
初期返回 ['id', 'name'] 很轻量，但后续加字段（如 'email'）可能破坏旧代码——尤其当调用方用 list($id, $name) = getBasicInfo(); 解构时。
- 禁止用
list()或[$a, $b] = ...解构关联数组返回值；若必须解构，用extract()（慎用）或显式赋值 - 新增字段时保持向后兼容：不删旧键、不改键名、不改变已有键的类型或含义
- 对可能扩展的接口，可在文档中注明“未来可能增加其他字段”，并建议调用方用
isset()或??安全访问可选字段
