Go中curryAdd等柯里化函数必须手动编写，因其缺乏动态参数绑定、反射式签名解析及泛型自动推导能力；类型系统不兼容不同参数个数与类型的函数，无法统一柯里化接口。
curryAdd 这类函数在 Go 里不是语言内置能力，而是靠闭包手动构造出来的——它不自动推导、不泛型支持、不兼容多参数原函数，必须为每个目标函数手写一层适配。
为什么 curryAdd 必须手动写，不能“一键柯里化”
Go 没有动态参数绑定或反射式函数签名解析机制。一个 func(int, int) int 和 func(string, bool, float64) error 在类型系统里完全不兼容，无法用统一接口包装。
- 你不能把任意函数传给某个
Curry工具函数并期望它返回柯里化版本 - 所有柯里化实现都依赖“已知参数个数 + 已知类型”的硬编码结构
- 比如
curryAdd(a int) func(int) int只对两参数int加法有效；换成三参数或混合类型就得重写整个签名
curryAdd 和 partialTimes 的本质区别
二者看起来都是“固定第一个参数”，但语义不同：前者是严格柯里化（只接受单参数、链式调用），后者是部分应用（可一次接收剩余全部参数）。
-
curryAdd(5)(10)是两步调用，中间返回的函数类型是func(int) int -
partialTimes(2)返回的是func(int) int，但它的设计意图就是“固定乘数，等待被乘数”，不强调“必须分步”，只是恰好支持单参数 - 如果你需要
partialTimes(2)(3)(4)（即支持继续柯里化），就必须手动再嵌一层，Go 不会自动递归生成
多层柯里化（如 tripleCurry）的实际代价
每多一层，函数类型就更具体、更难复用。三层柯里化函数的类型是 func(int) func(string) func(bool) string，它和两层、四层之间没有任何共用接口。
- 无法用同一个变量存不同层数的柯里化结果
- 调试时堆栈里会出现大量匿名函数嵌套，IDE 跳转易失效
- 如果某层参数是
[]byte或map[string]int，类型声明迅速变得不可读 - 示例中
tripleCurry5最后一层返回func(float64)，但你没法把它和tripleCurry4的返回值做任何类型统一操作
什么时候该用，什么时候该放弃
柯里化在 Go 中不是银弹，它只在非常明确的场景下值得引入：
立即学习“go语言免费学习笔记（深入）”；
- 配置驱动逻辑：比如
logWithLevel("debug")返回一个func(...string)日志函数，后续每次调用都不再重复传 level - 测试桩构造：固定 mock 的行为参数，如
mockDBQuery("users")返回一个可多次调用的查询函数 - 避免重复传入上下文：如
withTimeout(ctx, 5*time.Second)返回一个封装了超时控制的请求函数 - 但如果你只是想简化
f(a, b, c)→f(a)(b, c)，不如直接写fPartial(a) = func(b, c) { return f(a,b,c) }—— 更直白、类型更稳、IDE 更友好
真正容易被忽略的点是：Go 的柯里化函数一旦写出，就锁死了参数顺序和数量。没有 runtime 类型擦除，也没有泛型约束推导，改一个参数位置，整条调用链就得重写。
