超长业务逻辑函数应拆分为单一职责的独立函数，每函数不超过20行，按边界（if、循环、http/db调用等）拆分，避免伪拆分；依赖通过结构体注入，参数精简；错误类型明确、分层处理；测试需验证解耦与纯内存逻辑。
超长业务逻辑函数不是“写得快”，是“改不动、测不了、不敢动”。拆分不是为了凑行数，而是让每个函数能被独立理解、单独测试、清晰命名。
函数长度超过20行就该拆
Go 里没有硬性行数限制，但超过 20 行的函数大概率混了多个职责。比如一个 ProcessOrder 函数里同时做参数校验、库存扣减、支付调用、通知发送、日志记录——这根本没法单测，也没法定位哪一步出错。
- 先扫描函数内是否有明显边界：if 块、for 循环、HTTP 调用、DB 操作、error 处理 —— 这些都是天然拆分点
- 把每个边界动作封装成独立函数，哪怕只被调用一次，例如
validateOrderInput、decreaseInventory、notifySlack - 避免“伪拆分”：不要把
if err != nil { return err }单独抽成handleError，这不是职责，只是重复模式
拆分后参数传递要干净
拆分后最常踩的坑是把一堆无关参数塞进每个子函数：ctx、logger、db、config 全传一遍。这说明没理清依赖边界。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 只传该函数真正需要的输入：比如
decreaseInventory只需要orderID和items []Item，不传*sql.DB - 把共享依赖（db、logger）通过结构体字段注入，而不是函数参数：定义
type InventoryService struct { db *sql.DB; logger *zap.Logger }，方法接收者自然持有 - 如果某个子函数需要跨层信息（比如从 HTTP header 提取 traceID），用
context.WithValue透传，别加到函数签名里
错误处理必须随拆分同步重构
原函数里嵌套五层 if err != nil，拆完还保持同样结构，等于白拆。错误应该在职责边界处收敛或转换。
- 子函数返回明确的 error 类型，比如
ErrInsufficientStock，而不是泛化的errors.New("stock not enough") - 上层函数用 switch 判断具体 error，决定是重试、降级还是直接返回 HTTP 400
- 避免在子函数里直接
log.Fatal或 panic；错误传播路径要清晰，让 handler 层统一做响应包装
测试覆盖率会立刻暴露拆分质量
拆完之后跑单元测试，如果发现某个子函数必须 mock 整个 service 才能测，说明它还没真正解耦。
-
validateOrderInput应该纯内存操作，不依赖任何外部服务，测试只需给 struct 输入，断言 error 或 bool 返回 -
decreaseInventory如果依赖 DB，就定义InventoryRepo接口，测试时用内存实现（如 map）替代 pg 实现 - handler 层测试只验证参数解析和响应状态码，不测业务逻辑——那部分由 service 层覆盖
最难的不是怎么拆，而是每次写新逻辑时，下意识问一句：这个函数如果明天被另一个微服务复用，它的输入、输出、错误类型，是否依然成立？答案是否定的，就得重设计。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
