链式调用必须返回指针，否则编译失败；错误需存于结构体字段并由终接方法统一暴露；go仅包裹最左侧表达式；HTTP中间件是函数组合，非方法链。
链式调用必须返回指针，否则编译失败
Go 中链式调用失败最常见原因：方法用了指针接收器但返回值是值类型。比如 func (s *String) tolower() String —— 这里 tolower 修改了 *s，但返回的是 String（值），下一次调用 .toupper() 时，接收者变成临时值，而 Go 不允许对临时值取地址，直接报错：cannot call pointer method on。
解决办法只有一条：所有链式方法必须返回指针。
- 把
func (s *String) tolower() String改成func (s *String) tolower() *String - 构造函数也得返回指针：
NewPerson()必须返回*Person，否则第一次调用就断链 - 切忌混用值/指针接收器：同一个类型上，如果部分方法用值接收器、部分用指针，链会在值方法后中断（值方法返回副本，后续指针方法无地址可取）
错误处理不能靠 return error，得靠内部 err 字段
Go 的 error 是返回值，没法自然融入链式调用。强行让每个方法都返回 (T, error) 会破坏链式语法（因为返回两个值，无法继续点调用）。
正确做法是把 err 当作构建器的内部状态：
立即学习“go语言免费学习笔记（深入）”；
- 在 builder 结构体中声明
err error字段 - 每个链式方法开头检查
if b.err != nil { return b }，跳过执行 - 终接方法如
Build()或Validate()才统一暴露 error，例如：func (b *Builder) Build() (User, error) { return b.user, b.err }
不调用终接方法，err 就永远藏在结构体里，容易漏判 —— 这是最大隐患。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
go 关键字只包裹最左侧表达式，别误以为整条链并发执行
写 go b.SetName("x").SetAge(25).Build() 看似启动整个链，实际只有 b.SetName("x") 被调度，SetAge 和 Build 是它的返回值上的方法调用 —— 但主 goroutine 可能早已退出，导致 panic 或静默丢弃。
go 关键字只包裹最左侧表达式，即 b.SetName("x") 被调度，其余是它的返回值上的方法调用。
- 若需并发执行完整链，必须显式同步：用
chan struct{}或sync.WaitGroup - 更安全的做法是：先完成链式调用得到结果，再用
go启动后续逻辑
HTTP 中间件链 ≠ 方法链，别混淆底层机制
很多人看到 loggingMiddleware(authMiddleware(handler)) 就以为这是“链式调用”，其实这是函数组合（function composition），不是方法链（method chaining）。两者底层机制完全不同。
中间件链本质是高阶函数嵌套，每次包装生成新 handler，不依赖对象状态；业务链式调用依赖一个可变对象（如 *Builder），每步修改其字段。
- 中间件可以提前终止（
return不调next.ServeHTTP），业务链通常不中断，只记错、最后统一 fail - 混用二者容易误判控制流 —— 比如把 builder 方法写成中间件风格，反而丢失链式语义
- 标准库
http.Handler链必须返回接口实现体，不是http.HandlerFunc别名
链式调用真正难的不是写法，而是状态一致性与错误传播路径——一旦漏掉终接方法或误用 goroutine，问题往往静默发生，排查成本远高于预防成本。
