go中无语言级纯函数约束，但可写出事实纯函数：输入确定、无副作用、不依赖外部状态；须同时满足相同输入恒得相同输出、不修改外部状态、不触发任何副作用。
Go 里没有“纯函数”语言级约束，但你可以写出事实上的纯函数：输入确定、无副作用、不依赖外部状态。关键不是语法，而是写法和约束意识。
纯函数的三个硬性条件
纯函数必须同时满足：
- 相同输入永远返回相同输出（比如
func add(a, b int) int { return a + b }满足；func now() time.Time不满足） - 不修改任何外部变量、全局状态、传入的指针或 slice 底层数组（哪怕
func mutate(s []int) { s[0] = 99 }看似简单，也违反纯性） - 不触发任何副作用：不写文件、不发 HTTP 请求、不打日志、不调用
rand.Int()或time.Now()
注意：Go 允许你返回新 slice（如 append(s, x)），只要不复用原底层数组——这是安全的；但 s = append(s, x) 赋值本身不破坏纯性，前提是调用者没把原 slice 传给别的地方共享。
如何让业务逻辑“变纯”？
真实业务几乎都有 IO 和状态，所谓“函数式应用”，是把可纯化的部分坚决剥离出来，交给纯函数处理。
- DTO 校验：用
func (r *CreateUserRequest) Validate() error，只读字段、只返回 error，不改r本身 - 领域对象转换：写
func FromDTO(req *CreateUserRequest) (*User, error)，输入 req 是只读的，输出新*User，内部不碰数据库或缓存 - 计算逻辑：金额四舍五入、时间区间交集、JSON 字段提取——全写成
func(input T) Output形式，测试时可直接喂数据断言
一旦发现函数里出现 db.Query、log.Printf、os.WriteFile，就该立刻拆分：把计算部分抽成纯函数，IO 部分留在 handler 或 service 层调用它。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
闭包 ≠ 纯函数，小心隐式状态泄漏
闭包容易伪装成纯函数，实则暗藏状态。比如这个常见错误：
func makeCounter() func() int {
count := 0
return func() int {
count++
return count
}
}
每次调用 makeCounter() 返回的函数都带独立 count，看似没问题——但它本身不是纯函数：两次调用同一闭包实例，结果不同。
- 若你需要可复现的计数逻辑，应改为
func countFrom(start int, step int) int，输入完全决定输出 - 若必须用闭包封装状态（如缓存、连接池），那就明确承认它“不纯”，别塞进纯函数管道里参与 compose 或 map
- for 循环中捕获迭代变量是高频坑：
for _, v := range items { fns = append(fns, func() { println(v) }) }最终所有闭包都打印最后一个v值；正确写法是for _, v := range items { v := v; fns = append(fns, func() { println(v) }) }
泛型 + fp-go 能帮你写得更“函数式”，但不能替代设计判断
像 fp-go 提供的 Map、Filter、Option 等，确实能让数据流更清晰，但它们只是工具层。
-
fp.Map(slice, func(x int) string { return fmt.Sprintf("%d", x) })是纯的，只要你的映射函数是纯的 - 但如果你在
Map的回调里调用了http.Get，整个链就不再是纯函数式，而只是语法糖包装的副作用调用 - 泛型类型参数（如
func[T any, U any] Map([]T, func(T) U) []U）能提升类型安全，但无法阻止你在实现里写fmt.Println
真正难的从来不是怎么写 func，而是判断哪一段逻辑值得且能够被纯化——这需要对业务边界的清醒认知，而不是库或语法的堆砌。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
