Go微服务安全需四层设防：JWT须显式校验exp/alg/aud/iss并禁用none算法；HTTP通信须防SSRF，校验协议、IP与域名；服务间必须启用mTLS并严格验证双向证书；限流须按路径独立配置且绑定用户身份凭证。
Go 微服务不是加个中间件或配个 TLS 就算“防住了”。真正有效的防护，是把安全逻辑拆进每个环节：认证怎么传、通信怎么验、凭据怎么管、容器怎么跑——漏掉任何一环，攻击者都可能绕过。
JWT 验证必须显式校验 exp/alg/aud/iss
只调用 token.Valid 是常见错误。签名有效 ≠ token 可用：过期的 token、被篡改的 aud、伪造的 iss，都会让 token.Valid 返回 true，但业务已失守。
- 必须用
jwt.ParseWithClaims+ 自定义Keyfunc，避免密钥硬编码或复用 - 解析后强制检查：
claims.VerifyExpiresAt(time.Now().Unix(), true)（注意第二个参数不能为false） - 显式比对
claims["aud"]和claims["iss"]是否匹配预设值（如"payment-service"） - 检查
token.Header["alg"]是否为"HS256"或"RS256"，直接拒绝"none" -
sub字段只放用户唯一标识，别塞权限列表、手机号、邮箱等敏感字段
HTTP 客户端调用下游时必须防 SSRF
微服务常通过 http.Client 调用其他服务，一旦 URL 来自用户输入（比如 webhook 地址、回调配置），就极易触发内网探测或数据库直连。
- 禁用
http.DefaultClient，所有出向 client 显式设置Transport，并启用自定义DialContext做域名/IP 白名单校验 - 用
net.ParseIP+privateIP.IsPrivate()检查解析后的 IP，直接拒绝私有网段 - 对域名做 DNS 解析后校验（不能只看字符串是否含
.local） - 上游服务若需传 URL，应限制协议为
https，禁止http、file、ftp等非标准 scheme
服务间通信必须启用 mTLS 且 ClientAuth 配置正确
HTTP/TLS 单向加密只是防窃听；不验证对方身份，就防不住伪造请求和中间人重放。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 服务端
tls.Config.ClientAuth必须是tls.RequireAndVerifyClientCert（不是VerifyClientCertIfGiven） -
tls.Config.ClientCAs必须加载客户端证书的根 CA 证书池（不是客户端自己的证书） - 客户端发起连接时，
tls.Config.RootCAs要加载服务端 CA，tls.Config.Certificates要加载自身完整证书链（含中间证书） - gRPC 场景下，用
peer.FromContext(ctx)获取证书后，必须用x509.VerifyOptions校验签名，并检查Subject.Organization是否可信
限流必须按路径独立配置且绑定用户身份
防刷票不是靠 IP 或设备指纹，而是把动作锚定在短期有效的身份凭证上。
- 用
golang.org/x/time/rate.Limiter，每个接口路径配一个独立实例（比如每秒 5 次） - 不要全局复用同一个
Limiter，否则/login和/vote共享额度会误伤正常用户 - 投票前查数据库确认该用户今日未投过此选项，而不是只查缓存（缓存可能穿透或未及时失效）
- 必须要求调用方携带短期有效的
access_token，且 token 绑定user_id和后端生成的设备唯一标识（不依赖前端） - 避免用手机号或邮箱做唯一键直接查库，高并发下易成瓶颈；改用预生成的
user_id + vote_item_id + date组合键查 Redis
最危险的漏洞往往藏在“看起来已经做了”的地方：比如 token.Valid 返回 true 就放行、X-Forwarded-For 直接取第一个 IP、mTLS 的 ClientAuth 设成 VerifyClientCertIfGiven……这些都不是配置遗漏，而是逻辑错位。
