spiffe身份验证需显式实现：用workloadapi.newx509source获取svid并重试初始化，监听watch()更新tls.config；客户端校验须在verifypeercertificate中手动解析uri san并严格匹配spiffe://格式，grpc需从verifiedchains提取证书链，且各环节必须处理证书轮换与失败策略。
spiffe-go 不是验证器，它只是客户端 SDK；真正做身份验证的是你代码里写的 VerifyPeerCertificate 回调或 gRPC 的 tls.Config.GetConfigForClient —— 验证逻辑必须你自己写，SPIRE 只负责发证书。
怎么让 Go 服务从 SPIRE Agent 拿到 SVID
关键不是“连上 Agent”，而是用对 workloadapi.NewX509Source 并正确处理 context cancel 和重试。
-
X509Source初始化后会自动监听 Unix socket（默认/run/spire/sockets/agent.sock），但若 Agent 启动慢于你的服务，NewX509Source会立即失败并 panic —— 必须包一层重试逻辑，比如用backoff.Retry或简单 for-loop + time.Sleep - 证书更新不是静默的：
X509Source会在 SVID 过期前 10% 时间触发轮换，但你的tls.Config不会自动刷新 —— 必须监听X509Source.Watch()返回的 channel，在收到新证书时原子替换tls.Config.Certificates - 别在
main()里直接defer x509Source.Close()：gRPC 或 HTTP server 启动后仍需证书续期能力，应绑定到 server shutdown lifecycle
如何在 HTTP Server 中强制校验客户端 SPIFFE ID
Go 的 crypto/tls 不解析 URI SAN，也不校验 spiffe:// 格式 —— 所有校验都得手动写进 VerifyPeerCertificate。
- 必须设置
ClientAuth: tls.RequireAndVerifyClientCert，否则 TLS 层根本不请求客户端证书 -
ClientCAs要加载 SPIRE 的根 CA（即spire-server.crt），不是 workload 证书本身；这个池子只用于链验证，不参与 SPIFFE ID 提取 - 在
VerifyPeerCertificate回调里，遍历cert.URIs，逐个检查是否匹配白名单（如spiffe://example.org/ns/default/sa/payment）；注意大小写敏感、scheme 必须是spiffe://、且不能只比对 domain 部分（攻击者可伪造spiffe://evil.org/...） - 别用
strings.Contains做模糊匹配 ——spiffe://example.org/ns/default/sa/payment-db会被payment白名单误放行
gRPC 服务端怎么提取并验证对端 SPIFFE ID
gRPC 不像 HTTP 那样暴露 raw certificate，必须从 peer.AuthInfo 解包 credentials.TLSInfo，再手动解析证书链。
- Interceptor 中拿到
peer.AuthInfo后，要先断言为credentials.TLSInfo，再取TLSInfo.State.VerifiedChains[0]—— 这才是经过 CA 验证后的完整链，[0][0]是 leaf cert - URI SAN 存在
leaf.URIs，不是leaf.Subject.CommonName；CN 字段在 SPIFFE 场景下无意义，甚至可能为空 - 如果服务部署在 Istio Sidecar 后，且启用了 SDS，
VerifiedChains可能为空 —— 此时需改用credentials.Bundle+spiffe-go的workloadapi.NewX509Source做二次校验，而不是依赖 TLS 握手结果 - 校验失败必须返回
status.Error(codes.Unauthenticated, "...")，不能只 log 然后放行 —— gRPC 默认不中断调用流
为什么本地开发时 curl 总报 “bad certificate”
这不是 Go 代码问题，而是环境链路没对齐：SPIRE Agent、证书路径、curl 参数三者必须一致。
- 确认
spire-agent是否真在运行：sudo systemctl status spire-agent或kubectl get pods -n spire；Agent 崩溃后 socket 文件残留会导致 Go 客户端连上空 socket 并静默失败 - curl 测试时必须指定服务端证书的 CN 或 SAN：
--resolve api.internal:8443:127.0.0.1，且--cacert指向 SPIRE 根 CA，--cert和--key指向 workload client cert/key（不是 server 的） - Kubernetes 环境下，Pod 内访问
localhost不等于 hostNetwork；若 Agent 以 hostNetwork 运行，Pod 内必须用hostIP或通过 Downward API 注入 node IP 访问 Agent socket - 别用
http.DefaultTransport发起 mTLS 请求 —— 它完全忽略Certificates字段，必须显式构造http.Transport
tls.Config、URI SAN 校验用模糊匹配、gRPC Interceptor 里没做 VerifiedChains 判空。这些地方一漏，零信任就变成“零验证”。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
