Golang微服务安全需从认证、通信、存储、运行时四层设防：JWT须校验exp/iat/alg/aud/iss且禁用none算法；TLS须强制1.2+并白名单密套；敏感数据须AES-GCM加密且密钥不硬编；容器须非root只读运行。
golang 微服务不是加个中间件或配个 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字段只放用户唯一标识，别塞权限列表、手机号、邮箱等敏感字段
服务间通信必须启用 mTLS，且 ClientAuth 不能设错
HTTP/TLS 单向加密只是防窃听；不验证对方身份，就防不住伪造请求和中间人重放。
- 服务端
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等字段是否可信
容器必须以非 root 用户运行，且 USER 指令位置不能错
Go 二进制无依赖，容易被 exec 直接提权。若容器默认以 root 启动，一次内存越界就等于交出整个容器控制权。
-
Dockerfile中USER指令必须放在COPY之后、ENTRYPOINT之前 -
USER必须指定数字 UID（如1001），不能写用户名（镜像里未必存在） - Kubernetes 中需同时设置
securityContext.runAsUser: 1001和runAsNonRoot: true，否则 Pod 可能忽略镜像USER回退到 root - 别用
gosu或su-exec在启动时切用户——Go 进程不 fork，这种 runtime 切换无效，还多一层攻击面
HTTP 客户端调用下游时必须防 SSRF
微服务常通过http.Client 调用其他服务，一旦 URL 来自用户输入（比如 webhook 地址、回调配置），就极易触发内网探测或数据库直连。
- 禁用
http.DefaultClient，所有 client 显式构造并配置Transport -
Transport.DialContext必须做 IP 层白名单：用net.ParseIP+privateIP.IsPrivate()拒绝10.0.0.0/8、127.0.0.1、172.16.0.0/12、192.168.0.0/16 - 对域名要实际 DNS 解析后再校验，不能只靠字符串匹配（
localhost、host.docker.internal都得拦） - 上游传来的 URL 必须限制 scheme 为
https，禁止http、file、ftp、data
最易被忽略的是：JWT 的 exp 校验必须配合 time.Now().Unix() 手动比对，而不是依赖 token.Valid 的模糊判断；mTLS 的 ClientAuth 类型一旦设成 VerifyClientCertIfGiven，等于形同虚设；容器 USER 写在 ENTRYPOINT 之后，Docker 构建时根本不会生效。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
