jwt校验失败主因是密钥类型不匹配或算法未对齐；oauth2应收口至网关，下游服务仅验证可信header；服务间通信优先mtls或短期service token；/healthz需限制内网ip访问。
为什么 JWT 签发后无法在 Gin 中正确校验？
常见现象是 ctx.Get("user") 为空，或中间件里解析 token 时 panic：`square/go-jose: error in cryptographic primitive`。根本原因通常是密钥类型不匹配或签名算法未对齐。
- 使用
jwt.SigningMethodHS256时，Parse必须用[]byte类型密钥（不是字符串字面量直接传） - Gin 中推荐用
github.com/golang-jwt/jwt/v5（v5 而非 v4），因 v4 的ParseWithClaims默认不校验exp，需手动加VerifyExpiresAt - 签发时若用
time.Now().Add(24 * time.Hour)，但服务器时钟与客户端偏差大，会导致“明明刚登录就报 token 过期”
如何让 OAuth2 接入层不破坏微服务职责边界？
别在每个服务里重复实现 GitHub / Google 登录逻辑。应把 OAuth2 流程收口到 API 网关（如 Kong 或自研反向代理），只让下游服务处理已认证的 Authorization: Bearer xxx。
- 网关完成 code → token → 用户信息获取后，以 HTTP Header 注入可信字段，例如：
X-User-ID: 123、X-Auth-Scopes: read:orders,write:profile - 下游 Go 服务只需验证 Header 是否存在、是否由网关签名（比如检查
X-Auth-SigHMAC 值），无需碰 OAuth2 SDK - 若必须直连 OAuth2 提供方（如内部 LDAP），用
golang.org/x/oauth2，但Config.RedirectURL必须和注册时完全一致（含末尾斜杠），否则回调失败且错误提示极不明确
服务间调用怎么避免硬编码 Token 或泄露 secret？
内部 RPC 不该复用前端 JWT，更不该把 client_secret 写死在代码里。重点是区分「人对服务」和「服务对服务」两类认证。
- 服务间通信优先走 mTLS：用
crypto/tls配置ClientCAs和ClientAuth: tls.RequireAndVerifyClientCert，证书由内部 CA 统一签发 - 若用 Token，用短期（5min）的 service account token，通过环境变量或 HashiCorp Vault 注入，绝不用
os.Getenv("SECRET")直接读——改用vault.Read("secret/data/ms-auth")+ cache - Go 的
http.DefaultClient会复用连接，若为不同服务设置不同AuthorizationHeader，务必新建&http.Client{}实例，否则 header 会污染
如何快速拦截未授权的 /healthz 请求？
/healthz 通常被设计为免认证，但若它暴露了敏感指标（如数据库连接数、未处理消息量），就会成为攻击面。不能靠文档约定，得代码级控制。
立即学习“go语言免费学习笔记（深入）”；
- 在 Gin 中用
router.Any("/healthz", healthHandler)单独注册，不走全局 auth 中间件 - 但
healthHandler内部应调用checkInternalIP(r.RemoteAddr)，只允许来自 k8s10.96.0.0/12或 Consul agent IP 的请求 - 若用 Prometheus Exporter，确保
/metrics同样限制来源，且响应头加Cache-Control: no-store，防止 CDN 缓存敏感数据
实际最难的不是选 JWT 还是 OAuth2，而是让所有服务对「什么算可信请求」有一致判断——比如一个从 Istio sidecar 来的请求，Header 里有 X-Forwarded-Client-Cert，但你的 Go 服务没配置 tls.Config.VerifyPeerCertificate，那这个证书就只是个字符串。
