加密接口只需暴露Encrypt、Decrypt、GenerateKey三类方法；Hash和Sign/Verify应分离；IV、nonce等细节须在构造器中封装，不暴露底层类型；密钥初始化注入，不入方法参数；测试需覆盖空输入、超长输入、篡改密文及并发安全。
加密接口设计必须暴露哪些方法
Go 语言里做加密抽象，核心不是“支持多少算法”，而是定义一组稳定、可替换、不绑定具体实现的接口。实际项目中，你真正需要的只有三类操作：Encrypt、Decrypt、GenerateKey（或 DeriveKey），其余如 Sign/Verify 属于签名域，应拆到独立接口。
别把 Hash 塞进同一个接口——哈希是单向不可逆，和加解密语义冲突；也别提前暴露 SetIV 或 SetPadding 这类底层细节，它们属于具体实现的配置项，应在构造器（如 NewAESGCM）里收口。
示例接口定义：
type Cipher interface {
Encrypt(plaintext []byte) ([]byte, error)
Decrypt(ciphertext []byte) ([]byte, error)
}
type KeyGenerator interface {
GenerateKey() ([]byte, error)
}
如何避免 crypto/aes 和 crypto/cipher 的耦合陷阱
直接用 crypto/aes + crypto/cipher 写实现时，常见错误是把 cipher.BlockMode 或 cipher.Stream 当作返回值暴露出去——这会让调用方被迫处理 IV、nonce、padding 等细节，破坏抽象层意义。
正确做法是：在具体实现内部完成 IV 生成/拼接、nonce 管理、AEAD 封装，并统一返回带认证标签的密文（如 GCM 模式下，Seal 输出 = ciphertext + tag）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 使用
aes.NewCipher后，立即封装成cipher.AEAD（推荐 GCM 或 CCM），不再暴露原始Block - IV/nonce 必须随机生成且随密文一起输出（如 prepended），不要让调用方传入或管理
- 所有错误统一转为自定义错误类型（如
ErrInvalidCiphertext），不透出cipher.ErrInvalidLength这类底层错误
密钥派生与存储怎么和抽象层解耦
抽象层本身不负责密钥生成策略，但必须预留扩展点。比如 GenerateKey 接口看似简单，实际要区分场景：
- 对称密钥（AES）：通常用
crypto/rand.Read生成随机字节 - 基于口令的密钥（PBKDF2/scrypt）：应由上层传入
KeyDeriver实现，而非在 Cipher 实现里硬编码 - 硬件密钥（HSM/KMS）：通过回调函数注入，例如
WithKeySource(func() ([]byte, error) { ... })
关键点：密钥永远不出现在 Cipher 接口方法参数里。它应在初始化时注入，例如：
func NewAESGCM(key []byte) (Cipher, error) { ... }
// 或更灵活的选项式构造
func NewAESGCM(opts ...CipherOption) (Cipher, error) { ... }
测试抽象层时最容易漏掉的边界情况
单元测试不能只测 “加密后能解回来”。真实环境里，以下情况更常出问题：
- 空输入：
Encrypt(nil)是否 panic？应返回明确错误或允许（取决于业务） - 超长输入：AES-GCM 对单次加密长度有限制（约 64GB），不校验会静默失败
- 密文篡改：手动翻转密文最后 1 字节，
Decrypt是否返回AEAD verification failed类错误，而不是解出乱码 - 并发安全：同一个
Cipher实例是否支持 goroutine 并发调用？若内部缓存了 IV 或 nonce，就必须加锁或改用无状态设计
真正难的是让所有实现（AES、ChaCha20-Poly1305、未来可能的国密 SM4）在相同测试集下行为一致——这意味着抽象层契约必须足够严格，连错误类型都得约定好。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
