必须重构——参数超4个易错乱、难测试、耦合恶化；推荐用BookModel封装（语义明确、可校验）或PHP 8.0+命名参数（调用清晰），二者可分层混合使用。
PHP方法参数超过4个，就该考虑重构了——不是“可以优化”，而是“必须处理”，否则调用时极易传错顺序、漏传可选参数、难以测试，且后续加字段会越来越失控。
为什么不能硬扛参数膨胀
参数堆到6–8个时，create() 调用几乎变成拼图游戏：create($name, $cateId, $author, $year, $price, $publish, $country, $language)。没人能靠记忆保证第5个是$price而不是$publish；IDE自动补全也救不了顺序错位；单元测试里写一堆null占位更是在埋雷。
更实际的问题是：新增一个$isbn字段，所有调用点都得改，哪怕只用其中3个参数的场景也得补上null——这不是扩展性，是耦合恶化。
用 BookModel 封装参数（PHP 7.1+ 通用方案）
把散列参数收进一个明确语义的类，既保留类型提示，又解耦调用逻辑。关键不是“多写一个类”，而是让参数含义自解释、可复用、可校验。
立即学习“PHP免费学习笔记（深入）”；
- 定义
BookModel时，属性全部设为protected或private，强制走 getter/setter，避免直接赋值绕过业务约束 - 在
create()入口处立刻调用$model->validate()（可内置），比在方法体里写一串if (!isset($xxx))更干净 - 构造函数可接受数组或键值对，方便从
$_POST或 API 请求体直接实例化：new BookModel($_POST) - 别在
BookModel里塞业务逻辑（比如“生成书号”），它只负责数据承载和基础校验；复杂规则仍放在Book类或 Service 层
PHP 8.0+ 直接用命名参数（零成本升级）
如果项目已切到 PHP 8.0+，create() 方法本身不用大改，调用侧就能大幅降噪。前提是函数签名支持默认值、且不混用位置参数。
例如原函数：
function create(string $name, string $author, ?int $year = null, ?float $price = null, string $language = 'zh-CN'): array
调用时可写成：
$book = create(
name: '深入PHP',
author: '张三',
price: 99.9,
language: 'zh-CN'
);注意：name 和 author 是必填项，但顺序随意；year 完全跳过也没问题。这种写法不改变原有逻辑，却让调用意图一目了然。
容易踩的坑：
- 不能和位置参数混用：create('深入PHP', author: '张三') 会报错
- 匿名函数也支持命名参数，但 call_user_func_array() 不识别，需改用反射或显式展开
- IDE 对命名参数的支持度参差不齐，PHPStorm 2023.3+ 基本无感，老版本可能标黄警告
参数对象 vs 命名参数：怎么选
两者不互斥，而是分层使用：
- 内部方法间传递（如
BookService→BookRepository）优先用封装对象——它自带结构、可继承、可序列化、便于日志打印完整上下文 - 对外接口（如 Controller 接收请求、CLI 命令行参数）用命名参数更轻量，尤其当参数组合多变、且不常复用时
- 混合场景常见：Controller 用命名参数接收，转成
BookModel后再传给 Service——既保前端调用简洁，又保后端逻辑可控
最易被忽略的一点：无论选哪种，都要同步更新文档和类型提示。PHPStan/ Psalm 对 BookModel 的检查远强于对一堆松散参数的推断；而命名参数虽不用改函数体，但 @param 注释若还按旧顺序写，就会误导协作者。
