应先确认是否真需 ctxparam 规则，HTTP handler 不可加 context.Context 参数而应从 *http.Request 提取；仅底层 I/O 函数需暴露 ctx，且必须实际使用 ctx.Done/Err/Value 或传给下游 Context 函数。
golangci-lint 报 ctxparam 或 “missing context.Context” 怎么办
这不是语法错误，而是你启用了自定义或第三方 analyzer（比如 ctxparam），它在检查函数签名是否以 context.Context 为首个参数。常见于 HTTP handler、数据库操作、RPC 调用等需要可取消、可携带元数据的场景。
别急着加 context.Context —— 先确认这个规则是不是你项目真需要的。很多团队误启了未适配的 linter，结果所有工具函数、测试辅助方法全被报错。
- 查
.golangci.yml里是否显式启用了ctxparam（不是默认内置规则） - 运行
golangci-lint run --debug看输出中具体是哪个 linter 在报错 - 如果没主动配过，很可能是某依赖的
linters-settings里悄悄引入了该 analyzer
HTTP handler 必须带 context.Context 吗
标准 http.HandlerFunc 类型定义是 func(http.ResponseWriter, *http.Request)，不接受 context.Context。强行改签名会导致编译失败，因为 http.ServeMux 不认。
正确做法是：从 *http.Request 中提取上下文，而不是把 context.Context 当参数塞进 handler 函数签名。
- handler 内部用
r.Context()获取当前请求上下文 - 若需派生子 context（如加 timeout、value），用
context.WithTimeout(r.Context(), ...) - 不要写
func myHandler(ctx context.Context, w http.ResponseWriter, r *http.Request)—— 这无法注册到http.ServeMux
哪些函数该强制加 context.Context 参数
真正该加 context.Context 的，是那些可能阻塞、需支持取消、或要参与 trace/日志链路的**底层能力函数**，比如：
- 数据库查询：
db.QueryContext(ctx, ...)、tx.ExecContext(ctx, ...) - HTTP 客户端调用：
http.DefaultClient.Do(req.WithContext(ctx)) - 自定义异步任务启动器：
StartBackgroundJob(ctx, ...) - 文件读写（长耗时场景）：
os.OpenFile(..., ctx)（需封装）
关键判断标准：该函数是否直接或间接触发 I/O、网络、定时等待？如果是，且调用方需要控制生命周期（超时/取消），就必须暴露 ctx 参数。纯内存计算、简单结构体构造、单元测试辅助函数，不需要。
ctxparam analyzer 报错但修复后又出新问题
典型现象：加了 context.Context 参数后，golangci-lint 又报 SA1012: passing a context that is never cancelled（staticcheck 规则），或者 IDE 提示 “context passed to function not used”。
这是因为 analyzer 只检查“有没有”，不检查“有没有真用”。漏掉 ctx 的实际使用，等于白加。
- 必须在函数体内至少调用一次
ctx.Done()、ctx.Err()、ctx.Value()或传给下游带Context的函数（如db.QueryContext） - 禁止只声明
ctx context.Context却全程不引用——这会让调用方误以为该函数支持取消 - 若函数内部只是透传
ctx给下一层，确保下一层确实消费了它；否则删掉本层ctx参数更诚实
最易被忽略的是：加了 ctx 参数，却忘了把它的 Done() 传给 select 分支，或没在 goroutine 启动前做 ctx = ctx.WithCancel(...) —— 这类问题不会被 ctxparam 捕获，但会引发 goroutine 泄漏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
