因为crypto/tls封装标准TLS协议栈，自动处理密钥交换、前向保密、证书验证等全部安全细节；手动AES加解密无身份认证、防重放和降级防护，仅是混淆而非真正加密。
tls.Listen 为什么比手写 AES over socket 更安全
因为 crypto/tls 封装的是标准 TLS 协议栈，它自动处理密钥交换、前向保密（PFS）、证书验证、重协商、ALPN、SNI 等全部底层细节。你自己用 cipher.NewGCM + net.Conn 手动加解密，既没身份认证，也无防重放机制，更无法抵御降级攻击——这根本不是“加密”，只是“混淆”。
常见错误现象：
- 服务端启动后客户端连不上，报
x509: certificate signed by unknown authority—— 实际是证书链不全或 RootCAs 没加载对 - 连接建立成功但数据被中间设备（如代理、WAF）明文解析 —— 因为用了
InsecureSkipVerify: true，TLS 握手虽成，信任链已崩 - Go 客户端能连，curl 却报错
Certificate verification failed—— curl 默认校验系统 CA，而你的自签名证书没进系统信任库
服务端 tls.Listen 必须检查的三件事
调用 tls.Listen("tcp", ":8443", config) 前，确保以下三项对齐，否则监听失败或握手静默中断：
-
cert.pem必须含完整证书链：域名证书 + 中间证书（如 Let’s Encrypt 的 fullchain.pem），不能只放-----BEGIN CERTIFICATE-----块里的单张证书 -
key.pem必须是未加密私钥（即不含DEK-Info头），且 Linux/macOS 下权限 ≤0600；权限为0644时crypto/tls会直接拒绝加载，不报错只返回 nil -
tls.Config.Certificates必须用tls.LoadX509KeyPair("cert.pem", "key.pem")加载，不能把 PEM 字符串直接塞进去；返回的tls.Certificate是结构体，含Certificate、PrivateKey和可选SupportedSignatureAlgorithms
客户端 tls.Dial 如何正确信任自签名证书
服务端不用改，问题永远出在客户端配置。关键不是跳过校验，而是显式信任：
- 必须用
x509.NewCertPool()创建空池，再调用AppendCertsFromPEM([]byte(pemData))加载自签名证书的公钥（即cert.pem文件内容） -
tls.Config.RootCAs只接受 PEM 编码的证书块（-----BEGIN CERTIFICATE-----），绝不能塞私钥或中间证书 - 若证书是 OpenSSL 生成的，确认用了
-addext "subjectAltName=DNS:localhost"或配置文件注入 SAN；否则 Go ≥1.19 握手直接失败，报certificate is valid for xxx, not yyy - 不要设
InsecureSkipVerify: true—— 它会让 SNI、ALPN、甚至 Server Name 都失效，CI/CD 工具会扫描拦截该字段
加密强度与兼容性怎么平衡
默认 tls.Config 兼容性太宽，可能启用弱算法；但硬限死又导致老客户端连不上。折中做法：
-
MinVersion设为tls.VersionTLS12（Go 1.19+ 默认已是 TLS 1.2，但显式声明更稳） -
CipherSuites推荐只留 2–3 个强套件，例如：tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384、tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384；避免含SHA1或RC4的套件 -
CurvePreferences设为[]tls.CurveID{tls.CurveP256, tls.CurveP384}，禁用已被质疑的CurveP521和已淘汰的CurveSECP256K1 - 生产环境禁用
PreferServerCipherSuites: true—— 它会让服务器强制选自己列表里的第一个套件，反而降低协商成功率
最易被忽略的一点：证书签名算法必须匹配所选密码套件。比如你配了 ECDSA 套件，但证书是 RSA 签发的，握手就会失败，错误日志里往往只显示 remote error: tls: bad certificate，不提示具体原因。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
