Go中JWT认证Handler需用闭包捕获密钥，通过context.WithValue()安全透传用户数据，键须为私有类型；token从Authorization头提取，验证失败须http.Error并return；下游用r.Context().Value()配合类型断言获取用户信息。
Go 没有内置的“认证中间件”概念，所有认证逻辑都得自己用 http.HandlerFunc 或 http.Handler 显式封装；直接套库（比如 gorilla/sessions 或 auth0/go-jwt-middleware）反而容易在上下文透传、错误拦截、token 失效控制上翻车。
怎么写一个能透传用户信息的 JWT 认证 Handler
核心是闭包捕获密钥等配置，并把解析出的用户数据安全塞进 request.Context，下游才能拿到。别改 *http.Request 字段（它不可变），也别用全局变量存用户（并发不安全）。
-
context.WithValue()的键必须是私有类型（比如type userCtxKey struct{}），避免和其他中间件冲突 - token 必须从
Authorization: Bearer <token>头读，别硬编码从 query 或 form 取 - 验证失败时，必须显式调用
http.Error()并return，否则请求会继续往下走，可能泄露敏感数据 - 下游 handler 通过
r.Context().Value(userCtxKey{})拿用户 ID 或结构体，记得类型断言
为什么用 gorilla/sessions 做 Cookie 认证容易出问题
它默认用 securecookie 加密，但若没设对 MaxAge、HttpOnly、SameSite，登录后 session 就拿不到，或被 XSS 窃取。
-
session.Save()必须在写响应前调用，且只能调一次——多次调用会覆盖 header，导致 Set-Cookie 丢失 - handler panic 时，
session.Save()不会执行，用户登录状态就丢了 - Cookie 的
Domain和Path配错会导致跨子域失效，比如api.example.com写了Domain=example.com却没配SameSite=Lax
golang.org/x/oauth2 怎么集成授权码流程
这是最常用也最安全的 OAuth2 流程，适合 Web 应用。关键不是“怎么发请求”，而是怎么管好 state、code、token 三者的生命周期和存储边界。
立即学习“go语言免费学习笔记（深入）”；
-
conf.AuthCodeURL("state", oauth2.AccessTypeOffline)生成的 URL 必须带唯一state，防止 CSRF；这个state要存到 session 或短期缓存里，不能放 URL 参数明文传 -
conf.Exchange(ctx, code)返回的*oauth2.Token包含AccessToken和可选的RefreshToken，RefreshToken必须加密存服务端，不能塞进前端 Cookie - OAuth2 令牌本身不携带用户身份，得再调一次
userinfo端点（比如https://accounts.google.com/o/oauth2/v2/userinfo）拿sub或email - MCP 规范明确要求只支持 OAuth 2.1，且
JWT仅能作为访问令牌的载体格式，不能单独当认证方式用
Basic Auth 在什么场景下还能用
它简单、无状态、不依赖外部服务，但安全性低，只适合内部工具、CI/CD webhook、监控探针这类可信环境。
-
r.BasicAuth()解析的是Authorization: Basic base64(username:password)，用户名密码明文传输，必须配合 HTTPS - 别在生产 API 上对所有路由硬编码
username == "user" && password == "password"，至少查数据库或环境变量 - 如果要用，建议包装成独立中间件，和 JWT/OAuth2 共存：比如
/healthz走 Basic，/api/v1/走 Bearer - 注意重定向时
http.Client默认不携带 Basic Auth 头，需手动设置req.SetBasicAuth()或用自定义http.RoundTripper
真正难的不是写通一个 token 验证函数，而是让每个环节都守住边界：token 解析不泄漏错误细节、上下文传递不污染 key 空间、session 保存不被 panic 中断、OAuth2 state 不被复用。这些地方一松动，认证就形同虚设。
