Go微服务启用mTLS必须显式设ClientAuth为tls.RequireAndVerifyClientCert、配置非空ClientCAs、客户端提供完整证书链且私钥权限0600、RootCAs加载服务端CA、SAN字段完整，缺一即退化为单向TLS。
Go 微服务启用 mTLS 不是加个配置就完事，必须同时约束服务端 ClientAuth 模式、客户端证书加载、CA 信任链构建和 SAN 字段完整性——漏掉任一环都会导致握手失败或退化为单向 TLS。
服务端必须显式开启 ClientAuth 并加载 ClientCAs
仅靠 http.ListenAndServeTLS 或 tls.Listen 启动 HTTPS/mTLS 是不够的。服务端必须在 tls.Config 中设置 ClientAuth 并提供可信的客户端 CA 证书池。
-
ClientAuth: tls.RequireAndVerifyClientCert（最严格）或tls.VerifyClientCertIfGiven（可选验证） -
ClientCAs必须是非空的*x509.CertPool，不能只传nil或空池 - 若用自签名 CA，需先读取 CA 文件：
caCert, _ := os.ReadFile("client-ca.crt")，再调用caPool.AppendCertsFromPEM(caCert) - 服务端证书（
server.crt）与客户端证书（client.crt）必须由**同一套 CA 或互信 CA 体系**签发，否则校验失败
客户端必须双向携带证书并禁用 InsecureSkipVerify
客户端发起连接时，不仅得提供自己的证书链，还必须显式加载服务端 CA，且绝不能设 InsecureSkipVerify: true——这会绕过整个证书链校验，mTLS 形同虚设。
- 使用
tls.Dial时：传入含Certificates（客户端证书+私钥）和RootCAs（服务端 CA）的tls.Config - HTTP 客户端需配置
http.Transport.TLSClientConfig，其中Certificates和RootCAs都不可缺 -
tls.LoadX509KeyPair("client.crt", "client.key")加载客户端证书对，私钥权限必须 ≤0600 - gRPC 场景下用
credentials.NewTLS(&tls.Config{...})，不是credentials.NewClientTLSFromCert（后者不支持双向）
自签名证书必须带 subjectAltName（SAN），否则握手直接失败
Go 1.19+ 的 crypto/tls 对 SAN 强制校验，尤其在 HTTP/2（如 gRPC）场景下。OpenSSL 默认生成的证书不含 SAN，会导致 x509: cannot validate certificate for localhost because it doesn't contain any IP SANs。
立即学习“go语言免费学习笔记（深入）”；
- 生成服务端证书时，必须用配置文件或
-addext显式添加subjectAltName，例如：subjectAltName = DNS:localhost,IP:127.0.0.1 - 客户端证书同样需要 SAN（如
DNS:service-a），否则服务端校验客户端身份时失败 - 验证证书是否含 SAN：
openssl x509 -in client.crt -text -noout | grep -A1 "Subject Alternative Name" - 不要依赖
CN字段做主机名匹配——现代 TLS 已废弃该行为
go-zero 等框架中 mTLS 需绕过默认 HTTP 封装，直操作 tls.Config
go-zero 的 rest.MustNewServer 或 rpc.MustNewServer 默认不暴露 tls.Config 的完整控制权。若要启用 mTLS，必须放弃高级封装，手动构造底层监听器。
- 对 REST 服务：不用
rest.MustNewServer，改用http.Server+srv.ListenAndServeTLS，并在TLSConfig中设置ClientAuth和ClientCAs - 对 gRPC 服务：不用
zrpc.MustNewServer，改用grpc.NewServer(grpc.Creds(credentials.NewTLS(...)))，其中credentials.NewTLS的参数必须是完整配置的*tls.Config - 框架内置的 JWT 或 RBAC 中间件与 mTLS 是正交机制——mTLS 负责链路身份，JWT 负责用户身份，二者可叠加但不可替代
- 所有证书路径（
server.crt、client.key、ca.crt）应通过配置中心或环境变量注入，禁止硬编码或写死相对路径
真正卡住人的从来不是代码行数，而是证书链信任关系是否闭环、SAN 是否覆盖所有访问入口、以及 ClientAuth 和 ClientCAs 是否成对出现——这三个点任意一个出问题，错误日志往往只报 remote error: tls: bad certificate，没有更多线索。
