函数参数超4个需重构：优先拆分子行为、定义带validate方法的专属输入结构体，可选参数用选项模式，禁用map替代结构体，dto与domain分离，确保职责清晰。
函数参数超过4个就该重构了
Go里参数超4个的函数基本等于在埋雷：调用时容易传错顺序，加新字段要改所有调用点，单元测试得构造一长串值。这不是“能跑就行”的问题，是每次修改都多一层认知负担。
常见错误是把 struct 当成万能解药，直接塞一堆字段进去，结果发现这个 struct 在三个函数里被反复修改、复用逻辑混乱，反而更难维护。
- 优先提取有明确边界的子行为，比如
validateOrder、buildOrderRequest，让原函数只负责编排 - 如果参数确实属于同一业务实体（如订单创建所需全部数据），就定义专属输入结构体，但必须带
Validate()方法，且禁止导出未使用字段 - 避免用泛型或 map 替代结构体——
map[string]interface{}会让类型检查失效，IDE 无法跳转，错误只能 runtime 暴露 - 对可选参数，用选项模式（functional options）比布尔标记更清晰，例如
NewClient(WithTimeout(30*time.Second), WithRetry(3))
用选项模式替代布尔开关和零值哨兵
看到 createUser(name, email, isActive, isVerified, withProfile, withNotification) 这种签名，说明已经掉进“布尔爆炸”陷阱。每个 true/false 都在增加组合分支数，还掩盖了参数语义。
选项模式不是炫技，是让调用方只声明它关心的配置，其余走默认。关键是选项函数必须作用于同一个接收体，且不改变原始结构体状态。
- 选项函数签名统一为
func(*Config) error或func(*Config)，避免返回 error 增加调用负担 - 默认值应在结构体内置，不在选项函数里硬编码；例如
timeout: 5 * time.Second写在 struct 定义里，而非WithTimeout函数中 - 不要把业务逻辑塞进选项函数，比如
WithAuthCheck()应该只是设置标志位，认证逻辑留在主流程里 - 如果只有1–2个可选参数，直接用结构体字面量更轻量，不用强行上选项模式
DTO与Domain模型混用导致参数膨胀
HTTP handler 直接把 *http.Request 或 JSON 解析后的 map[string]interface{} 传给 service 层，是参数失控的起点。这会让 service 函数既要处理协议细节，又要执行业务逻辑，职责彻底粘连。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
真正该传进去的，是经过清洗、校验、转换后的领域对象，比如 order.CreateInput，而不是裸的 req.Body。
- 每个 API 接口定义专属 DTO，放在
api/v1/下，命名带版本（如CreateOrderV1Req） - DTO 不含方法，只含字段；校验逻辑写在独立函数里，如
func (r *CreateOrderV1Req) Validate() error - service 层接收的是 domain struct（如
order.Order），由 converter 函数从 DTO 映射而来，不能直接依赖 DTO 类型 - 禁止在 service 函数签名里出现
context.Context以外的基础设施类型，比如*sql.Tx、http.ResponseWriter
拆分后的新函数参数仍超限？说明职责没切干净
把一个20参数的函数拆成三个函数，每个还有8个参数，那只是物理挪动，不是重构。圈复杂度可能降了，但可读性和可测性没变好。
判断是否真拆干净，就看新函数能不能脱离原上下文独立存在：能否单独写单元测试？能否被其他模块复用？名字能不能一句话说清它做什么？
- 如果新函数名还带
Helper、Util、Internal，大概率职责模糊，再拆 - 参数超过3个，先问：其中有没有可以合并的？比如
firstName, lastName, email可以收进UserIdentity结构体 - 有没有本该由调用方准备好的？比如时间戳、ID生成器、logger，应该通过依赖注入传入，而不是作为参数塞进来
- 有没有其实是错误条件？比如
skipValidation bool，应该用早期返回代替：if skipValidation { return nil }
参数多本身不是病，病在它暴露了职责不清、边界模糊、层间泄漏这些深层问题。每次想加第5个参数前，先停两秒，看看是不是该把其中两个拎出去自立门户。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
