Go高阶函数必须先定义具名函数类型别名，如type Operation func(int, int) int，不可直接使用func(int, int) int字面量作参数类型；否则难以复用、测试和维护，且需显式校验nil、控制闭包变量生命周期、正确实现装饰器模式。
高阶函数必须先定义函数类型别名
Go 不允许把 func(int, int) int 这类字面量直接塞进参数列表当类型用，编译会报错。你得先用 type 显式声明一个具名函数类型，比如：type Operation func(int, int) int。否则不仅写不下去，后续想复用、测试、加文档都困难。
常见错误是写成这样：func calculate(x, y int, op func(int, int) int) int——语法上能过，但一旦多个地方要用相同签名，就得反复抄，改一处漏一处；单元测试里也难 mock，因为没统一类型入口。
- 类型名要带语义，比如
FilterFunc比func(string) bool更易懂 - 所有使用该行为的地方（如
Map、Filter、Reduce）都应引用这个类型名，而不是重写字面量 - 如果函数签名稍有不同（比如多一个
context.Context），就该另起一个类型，别硬塞可选参数
接收函数参数时务必检查 nil
Go 不做隐式空值防护，传进来的函数变量可能为 nil，尤其在配置驱动或动态构造调用链的场景下。漏掉检查，运行时直接 panic。
典型写法是加卫述逻辑：if op == nil { return 0, errors.New("operation cannot be nil") }。这不是防御性编程的“过度设计”，而是 Go 的实际约束：函数值是可比较的，且 nil 是合法零值。
立即学习“go语言免费学习笔记（深入）”；
- HTTP 中间件等场景中，
nil可能代表“跳过”，此时应显式走默认分支，而非让程序崩掉 - 泛型版
Map[T, U any]通常不内置 nil 检查，因为内联后仍 panic，所以调用方必须保障非空 - 不要依赖 defer 在函数退出时统一处理——panic 发生在调用点，不是 defer 所在作用域
返回函数时闭包捕获变量要控制生命周期
用 func() int 这类返回值创建闭包很常见，但闭包捕获的是变量的引用还是副本，直接影响行为是否符合预期。
安全示例：func Multiplier(factor int) func(int) int { return func(n int) int { return n * factor } }——factor 是值传递，被复制进闭包，生命周期由闭包自身管理。
- 危险模式：
for i := range items { go func() { fmt.Println(i) }() }，所有 goroutine 共享同一个i变量，最终全输出最后一个值 - 正确写法是立即传参：
go func(val int) { fmt.Println(val) }(i) - 闭包持有大对象（如整个 struct 或长 slice）会阻止 GC，内存占用可能远超预期
装饰器模式必须返回新函数，不能直接调用原函数
Go 没有 @decorator 语法，靠函数类型 + 闭包模拟装饰器，核心是：接收函数，返回函数。如果写成 return h(x)，那就只是普通调用，不是装饰。
典型结构是：func Logging(h Handler) Handler { return func(x string) error { log.Printf("start: %s", x); defer log.Printf("end: %s", x); return h(x) } }。注意 defer 必须放在闭包内部，否则它绑定的是装饰器函数体的执行上下文，不是被包装函数的生命周期。
- 耗时统计必须在闭包开头打点：
start := time.Now()，不能在外层打 - 若需透传 context，装饰器应接收
func(context.Context) error类型，并在闭包内构造新 ctx - 所有参数和返回值必须严格一致，否则编译失败或运行时 panic
真正的难点不在语法，而在判断：哪个行为该抽象成参数？哪个状态该封装进闭包？谁来负责空值校验和兜底？这些决策都落在类型定义和空值处理里，而不是 func 关键字表面。
