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 实现装饰器模式，函数链更符合函数式组合语义，也更容易单元测试。
本文档主要讲述的是OpenMP并行程序设计；OpenMP是一个编译器指令和库函数的集合，主要是为共享式存储计算机上的并行程序设计使用的。目前支持OpenMP的语言主要有Fortran，C/C++。 OpenMP在并行执行程序时，采用的是fork/join式并行模式，共享存储式并行程序就是使用fork/join式并行的。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
立即学习“go语言免费学习笔记（深入）”；
- 每个装饰器只专注一件事：日志、重试、熔断、指标打点
- 顺序很重要：重试装饰器应包在熔断器外层，否则失败后不会重试
- 避免在装饰器中修改原始函数的参数或返回值结构（比如把
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 的简洁性，恰恰体现在它允许你跳过模式，直击本质。
