函数应拆分的标准是：if嵌套超两层、for套if再套range、单函数超30行且职责不单一；gocyclo≥15必须拆，重点监控error返回但含校验+转换+DB+消息的函数；拆分后需补全测试、验证行为不变、命名动词开头、参数精简、避免中间态命名。
直接拆：只要函数里出现 if 嵌套超过两层、for 套 if 再套 range、或者单个函数超过 30 行且干了不止一件事，就该拆。这不是“建议”，是避免后续改出 panic: runtime error: invalid memory address 的基本操作。
识别该拆的函数：用 gocyclo 看圈复杂度
gocyclo 是最直接的判断工具。它把每个 if、for、range、&&、|| 都算作 +1，基础值为 1。结果 ≥10 就该警惕，≥15 就必须拆。
- 运行
gocyclo -over 15 ./... | head -20，列出所有高风险函数 - 重点盯住返回值类型为
error但内部做了校验+转换+DB写入+发消息的函数——这明显违反单一职责 - 别只看行数：一个 20 行但含 4 层
if+ 2 个switch的函数，比一个 50 行但全是线性赋值的函数更危险
拆分时怎么命名和组织：让函数名自己说话
名字不是为了“看起来高级”，而是让调用方一眼知道它干啥、不干啥、依赖什么。
- 用动词开头：
validateOrder、calculateDiscount、persistToDB，而不是handleOrder或processStep - 参数尽量只传必要字段：
validateOrder只需要orderID和items，不该接收整个*http.Request - 避免“中间态”函数名：
prepareData这种名字等于没说；换成normalizeItemNames或dedupePromoCodes - 如果拆出的函数只被一个地方调用，且逻辑简单（比如纯字符串处理），可定义为包内私有函数，以
lowercase开头
拆完怎么验证没改坏：别只跑一遍 test
重构不是“能编译就行”，重点是行为不变、边界不漏、错误不吞。
- 先补全原函数的单元测试，覆盖所有
if分支和错误路径——没测试就拆，等于蒙眼开车 - 拆完后，原函数变成薄胶水层：
func processOrder(...) error { if err := validateOrder(...); err != nil { return err } ... }，它的测试只需验证调用顺序和错误传递，不重复测子函数 - 对每个新函数单独加测试，尤其注意空输入、边界值、
nil指针——例如calculatePrice必须测items为空或单价为负的情况 - 用
go vet -shadow检查拆分后是否意外引入变量遮蔽（比如子函数里又声明了同名err）
真正难的不是拆，是判断哪块逻辑该归到哪个函数里。比如订单价格计算中，“是否使用优惠券”和“是否叠加满减”看起来都属于“计算”，但前者依赖用户状态，后者依赖商品库存，它们该拆成两个函数，而不是塞进同一个 calculatePrice。这种耦合点，得靠读业务语义，不是靠数 if 个数。
