命名参数使函数签名变更不再破坏调用方：只要参数名不变，调整顺序、增删中间参数均不影响旧调用；跳过可选参数无需null占位，语义清晰且IDE补全精准，但禁止与位置参数混用。
命名参数让函数签名变更不再破坏调用方
PHP 8 的命名参数把「参数名 → 实参值」的绑定关系从位置耦合解耦出来。只要函数定义中参数名不变，哪怕你把 $cc 插到 $subject 和 $body 中间，所有旧调用依然能正常运行。
常见错误现象：PHP 7 下改函数参数顺序后，调用处没同步更新，导致 $html 被误传给 $body，邮件内容被当成布尔值解析。
- 重构时可自由增删中间参数，无需批量修改调用点
- 重命名参数仍需全局搜索，但顺序调整完全零风险
- 配合 IDE 的重命名功能（如 PhpStorm），改名后自动更新所有命名调用
跳过可选参数时不再需要 null 占位
传统 positional 调用中，想只设 $format 却跳过 $height 和 $crop，就得写 createThumbnail($path, 100, null, 'webp')——null 含义模糊，且一旦后续加新默认参数，整个调用链都要补位。
使用命名参数后，createThumbnail(path: $path, format: 'webp') 直接表达意图，不依赖任何占位符。
立即学习“PHP免费学习笔记（深入）”；
- 可读性提升的关键在于：每个参数都自带语义标签，不靠位置猜含义
- IDE 能基于参数名给出精准补全，而位置参数只能靠顺序记忆
- 代码审查时，一眼看出是否遗漏了关键配置（比如漏了
html: true）
命名参数必须全部统一风格，不能混用位置参数
这是最容易踩的坑：一旦函数调用里出现任一命名参数（如 to: 'a@example.com'），其余所有参数都必须用命名形式。PHP 8 不允许 sendEmail('a@example.com', subject: 'Hi') 这种混合写法，会直接报错 ParseError: Named parameter cannot be used after positional argument。
- 已有项目迁移时，建议先全局搜索
function_name(，检查调用是否含位置参数 - 团队规范需明确：启用命名参数后，该函数所有调用必须一步到位改完
- 静态分析工具（如 PHPStan）目前对混合用法检测有限，靠人工或 CI 阶段的语法检查拦截
顺序不匹配会有轻微性能开销，但可读性优先
Zend 引擎在处理乱序命名参数（如 email: 'x', name: 'y', age: 30）时，需额外做一次参数位置映射重组。基准测试显示，10 万次调用中，无序比有序慢约 1.7ms —— 对绝大多数业务代码无感，但在高频循环（如导出 CSV 每行调用）中值得留意。
真正该关注的是：是否为了“性能”牺牲了可维护性。比如把 createUser(name: $n, email: $e, active: $a) 强行改成声明顺序，但团队约定是按业务逻辑分组（身份信息、状态、权限），那就不该妥协。
复杂点在于：可读性和性能不是非此即彼，而是要看上下文。重构时先确保语义清晰，再在 profiler 确认热点后针对性优化顺序。
