Go语言虽非函数式语言，但可用函数式思想编程：以函数为一等公民、减少副作用、用组合代替继承；策略模式宜用func类型而非struct+method，闭包封装上下文更自然。

Go 语言本身不是函数式语言，没有内置的高阶函数链、不可变数据结构或尾递归优化，但你可以用函数式编程思想来组织代码——关键不在语法糖，而在思维方式：把函数当一等公民、减少副作用、用组合代替继承、用纯函数抽象逻辑。设计模式在 Go 中往往要“降维”实现，不是照搬 Java 的类图，而是靠 func、interface 和组合来达成同样目的。

用 func 类型替代策略模式（Strategy）

传统策略模式依赖接口 + 多个实现类；Go 里直接用函数类型更轻量，也更贴近“行为即值”的函数式直觉。常见错误是过度封装成 struct+method，反而掩盖了核心逻辑的可组合性。

• func(int, int) int 可以直接作为策略传入，比如加法、乘法、取模
• 避免为每个策略定义一个 type Adder struct{} 再实现 Calculate() 方法——除非你需要携带状态（如带缓存的策略）
• 组合策略时，用闭包封装上下文比用 struct 字段更自然，例如：

  func withTimeout(f func() error, d time.Duration) func() error {
      return func() error {
          done := make(chan error, 1)
          go func() { done <- f() }()
          select {
          case err := <-done: return err
          case <-time.After(d): return fmt.Errorf("timeout")
          }
      }
  }

用 map[string]func(...) 实现命令模式（Command）时的陷阱

把命令注册为函数映射很常见，但容易忽略错误处理一致性、参数校验时机和生命周期管理。

• 不要直接存 func()，而应统一为 func(context.Context) error，便于超时、取消、日志注入
• 注册时不做 panic 式校验（如 key 重复），改用返回 error：Register(name string, cmd func(context.Context) error) error
• 避免在 map 中存闭包引用外部变量（尤其是指针或未拷贝的 struct），否则并发执行时可能读到脏数据
• 示例注册与调用：

  var commands = make(map[string]func(context.Context) error)
  func Register(name string, cmd func(context.Context) error) error {
  if _, exists := commands[name]; exists {
  return fmt.Errorf("command %q already registered", name)
  }
  commands[name] = cmd
  return nil
  }
  func Run(ctx context.Context, name string) error {
  cmd, ok := commands[name]
  if !ok {
  return fmt.Errorf("unknown command %q", name)
  }
  return cmd(ctx)
  }

装饰器（Decorator）不用 interface 嵌套，用函数链

Go 没有 Python 的 @decorator 语法，但可以用高阶函数模拟：接收一个 func，返回一个增强后的 func。比起用嵌套 struct 实现装饰器模式，函数链更符合函数式组合语义，也更容易单元测试。

• 每个装饰器只专注一件事：日志、重试、熔断、指标打点
• 顺序很重要：重试装饰器应包在熔断器外层，否则失败后不会重试
• 避免在装饰器中修改原始函数的参数或返回值结构（比如把 error 悄悄转成 *model.Error），会破坏调用方契约
• 典型写法：

  func withLogging(next func(context.Context) error) func(context.Context) error {
      return func(ctx context.Context) error {
          log.Printf("calling %v", runtime.FuncForPC(reflect.ValueOf(next).Pointer()).Name())
          return next(ctx)
      }
  }
  func withRetry(maxRetries int) func(func(context.Context) error) func(context.Context) error {
  return func(next func(context.Context) error) func(context.Context) error {
  return func(ctx context.Context) error {
  var err error
  for i := 0; i <= maxRetries; i++ {
  err = next(ctx)
  if err == nil || !shouldRetry(err) {
  break
  }
  if i < maxRetries {
  time.Sleep(time.Second * time.Duration(i+1))
  }
  }
  return err
  }
  }
  }
  // 使用：cmd := withLogging(withRetry(3)(originalCmd))

真正难的不是写出这些函数，而是判断何时该用函数式风格、何时该回归 Go 的朴素结构体+方法。比如需要共享大量状态、频繁修改字段、或必须满足某个已有 interface 时，硬套闭包只会让代码更难懂。函数式是工具，不是教条；设计模式是问题模板，不是填空题——Go 的简洁性，恰恰体现在它允许你跳过模式，直击本质。