go语言不原生支持柯里化，但可通过手动嵌套闭包模拟，如func(a int) func(b string) func(c bool) int，类型系统强制参数顺序与层级，仅适用于参数生命周期分离或前缀复用场景，多数情况推荐结构体、选项模式等更go式的替代方案。
Go 里没有原生 curry，但能用闭包模拟
Go 语言不支持像 Haskell 或 Swift 那样的自动柯里化，func(a, b, c) int 不能直接写成 func(a) func(b) func(c) int。你必须手动展开每一层返回函数，靠闭包捕获前置参数。这不是语法糖，而是显式构造：每多一个参数，就要多嵌一层 func(...) func(...)。比如三参数函数，就得写成 func(a int) func(b string) func(c bool) int —— 类型签名本身就暴露了“层数”，没法动态推断。
手写三层柯里化时，参数类型和顺序必须严格对齐
常见错误是把 tripleCurry(1)("hello")(true) 写成 tripleCurry("hello")(1)(true)，编译直接报错。Go 是静态类型语言，每层返回函数的输入类型由上一层决定，一旦错位就中断链式调用。示例中 tripleCurry 的第一层只接受 int，第二层只接受 string，第三层只接受 bool —— 没有运行时 fallback，也没有占位符（如 Lodash 的 _）。
- 参数顺序不能靠文档约定，得靠类型系统强制约束
- 如果某参数在业务中常为空或可跳过，别硬塞进柯里化链，改用结构体传参更安全
- 避免混合使用可变参数（
...T）和柯里化，两者语义冲突：前者强调“一次性收完”，后者强调“分步收”
柯里化在 Go 中真正适合的场景很窄
它只在两类情况值得用：参数分属不同生命周期，或需要复用固定前缀。比如 API 客户端封装：newClient(baseURL) 返回一个函数，再传 endpoint，最后传 method；又比如日志器预设 env 和 service 后，只留 msg 动态传入。但若所有参数都在同一时刻可得，直接写 func(a, b, c) error 更清晰、无闭包开销、无类型嵌套噪音。
- 不要为“函数式风格”而柯里化 —— Go 不鼓励这种抽象
- 链越长，调试越麻烦：堆栈里全是匿名函数名，
runtime.Caller定位困难 - 单元测试需逐层 mock，不如直接测完整函数
替代方案比手写柯里化更常用
多数 Go 项目用的是更务实的替代方式：struct + 方法链、选项模式（Option 函数）、或简单闭包封装。例如：
type Logger struct {
env, service string
}
func (l *Logger) Info(msg string) { /* ... */ }
<p>// 或
type ClientOption func(<em>Client)
func WithBaseURL(u string) ClientOption { /</em> ... <em>/ }
func NewClient(opts ...ClientOption) </em>Client { /<em> ... </em>/ }
</p>
这些写法类型安全、易读、易扩展，且不引入额外闭包层级。柯里化在 Go 中是个“能做但不推荐高频使用”的技巧 —— 它解决的问题，往往有更 Go 的解法。
