AES密钥长度必须严格匹配：128位需16字节、192位24字节、256位32字节；ECB模式未被Go标准库支持；推荐使用GCM等AEAD模式，IV/nonce须随机且唯一，密钥与数据须正确编码（如hex/base64），严禁字符串字面量直接转[]byte。
用 aes.NewCipher 前必须确保密钥长度合法
Go 的 aes.NewCipher 不会自动补位或截断密钥，传入错误长度的 []byte 会直接 panic：crypto/aes: invalid key size 16（注意：这个错误信息其实反直觉——16 是合法的，但如果你传了 17 或 23，它才报这个错，且不提示真实原因）。
- AES-128 要求密钥正好 16 字节（不是 16 个字符！中文、emoji 都可能占多字节）
- AES-192 → 24 字节，AES-256 → 32 字节
- 别用
md5([]byte("my-key"))直接当密钥——md5输出是 16 字节，只能用于 AES-128；想通用就用sha256再截取 - 推荐做法：
sha256.Sum256(key).[0:32]，再按需切片
ECB 模式在 crypto/cipher 里根本没实现
你翻遍 Go 标准库文档也找不到 cipher.NewECBEncrypter ——不是漏写，是故意不提供。ECB 安全性太差，连标准库都拒绝背书。
- 常见误操作：网上抄代码时硬凑
ecb.NewECBEncrypter，结果编译失败或要额外引入非官方包（比如github.com/fernet/fernet-go） - 生产环境只考虑
cipher.NewCBCEncrypter或cipher.NewGCM（后者更推荐） - CBC 需要 IV，且必须每次加密随机生成；IV 不需要保密，但绝不能复用——常有人把 IV 写死成
make([]byte, 16)导致加密可预测
cipher.AEAD.Seal 返回的密文自带认证标签，别手动拼接
用 GCM（cipher.NewGCM）时，Seal 输出是 nonce || ciphertext || tag，但这个结构是内部约定，不是协议规范。你自己拼 append(nonce, cipher...) 就等于绕过 AEAD 安全模型。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确做法：调用
aead.Seal(dst, nonce, plaintext, additionalData)，让 Go 自己处理格式 - 解密时必须用同一个
nonce和additionalData，否则Open直接返回crypto/cipher: message authentication failed - nonce 长度取决于具体 AEAD 实现（GCM 通常 12 字节），不能随意设为 16 或 8
- 如果要网络传输，建议把
nonce单独发，再发Seal结果（不含 nonce），避免混淆边界
字符串到字节切片的转换容易丢数据
加密操作全程基于 []byte，但人习惯输 "hello" 这种字符串。Go 里 string 到 []byte 是拷贝，看着没问题，但遇到非 UTF-8 数据（比如原始密钥、从文件读的二进制 key）就容易出错。
立即学习“go语言免费学习笔记（深入）”；
- 别写
[]byte("my-key-32-bytes-long-...")——字符串字面量默认 UTF-8 编码，中间有 \x00 就被截断 - 密钥/IV 从配置来？优先用 hex 或 base64 解码：
hex.DecodeString("a1b2c3...")，别手写字节切片 - 加密后想存成字符串？必须编码：
base64.StdEncoding.EncodeToString(ciphertext)，别直接string(ciphertext) - 日志里打印密文？先截断或打码——完整输出可能含控制字符，导致终端乱码甚至执行隐藏命令
密钥管理、IV 生成、编码方式、AEAD 标签处理——这些环节任意一个松动，加密就只剩「看起来像加密」。实际跑通不难，难的是每一步都不妥协。
