go中闭包捕获变量引用而非值，多协程下共享变量会导致竞态；循环中直接启动goroutine会全部捕获同一变量地址，最终都读到循环结束值。
Go 里用闭包传递上下文到子处理器是安全的，但前提是闭包捕获的是值而非共享变量引用；否则在多协程场景下会出错——比如所有 goroutine 都读到同一个 ctx 的最终状态，或更糟：读到已被释放/覆盖的内存。
闭包捕获的是变量引用，不是快照
闭包不复制变量，只绑定变量地址。如果在循环中直接用 go func() { use(i) }()，所有 goroutine 实际共享同一个 i 变量，最终都看到循环结束后的值（如 i == 10）。
- 错误写法：
for i := 0; i → 全部输出 <code>5 - 正确写法：
for i := 0; i → 输出 <code>0到4 - 等价安全写法：
for i := 0; i
子包处理器工厂函数必须显式接收 *core.Context
把上下文注入逻辑从「全局变量」移到「函数参数」，才能保证每个处理器实例拥有独立、确定的上下文副本。否则测试时无法 mock，运行时可能因并发修改 ctx 字段引发 panic 或数据污染。
-
Create必须是工厂函数：func Create(ctx *core.Context) httprouter.Handle，不能是func Create() httprouter.Handle且内部读全局c - 路由注册时传入当前有效上下文：
router.POST("/token", token.Create(appCtx))，而非router.POST("/token", token.Create()) - 若上下文含可变字段（如
ctx.UserID），确保它在 handler 执行前已设置完毕，且不被其他 goroutine 并发修改
并发调用闭包处理器时，ctx 生命周期必须覆盖整个请求周期
闭包捕获的 *core.Context 指针，其底层结构体可能包含连接池、logger 实例等长生命周期对象，但本身不应依赖栈上临时变量。若 ctx 是从某个局部作用域传入（如函数参数），需确认它不会在 handler 执行中途被 GC 或重用。
- 推荐来源：
appCtx应来自main()或启动时初始化的单例，生命周期与进程一致 - 禁止来源：
ctx不应来自某个中间函数的栈变量，例如func handle(w, r) { localCtx := newContext(); handler := token.Create(&localCtx); handler(...) }——localCtx可能在 handler 运行前就失效 - 验证方式：在 handler 内打印
fmt.Printf("%p", ctx)，确认每次调用地址稳定且非栈地址（如高位为0xc0而非0x7fff）
真正容易被忽略的不是“怎么写闭包”，而是“谁 owns 这个 *core.Context”。一旦上下文生命周期管理出错，闭包再规范也救不了并发数据竞争。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
