使用crypto/aes需手动处理IV和PKCS#7填充，密钥长度须为16/24/32字节；推荐crypto/cipher.AEAD（如GCM）自动处理IV与认证；禁用MD5/SHA1派生密钥，应使用PBKDF2等KDF；文件加密须分块流式处理并正确填充。
用 crypto/aes 做 AES 加密必须手动处理 IV 和填充
Go 标准库不提供开箱即用的「加密字符串→密文」函数，aes.NewCipher 只返回底层加解密器，你需要自己管理 IV（初始化向量）和 PKCS#7 填充。漏掉任一环节都会导致解密失败或 panic。
- IV 必须每次加密随机生成，且和密文一起传输（通常前置在密文前）
- Go 没有内置 PKCS#7 填充函数，得自己补字节：明文长度不足块大小（16 字节）时，在末尾追加
n个值为n的字节 - 密钥长度必须严格为 16（AES-128）、24（AES-192）或 32（AES-256）字节；传入
[]byte("my-key")很可能只有 6 字节，直接 panic
func encryptAES(plaintext []byte, key []byte) ([]byte, error) {
block, err := aes.NewCipher(key)
if err != nil {
return nil, err
}
if len(plaintext)%block.BlockSize() != 0 {
padding := block.BlockSize() - len(plaintext)%block.BlockSize()
plaintext = append(plaintext, bytes.Repeat([]byte{byte(padding)}, padding)...)
}
ciphertext := make([]byte, block.BlockSize()+len(plaintext))
iv := ciphertext[:block.BlockSize()]
if _, err := io.ReadFull(rand.Reader, iv); err != nil {
return nil, err
}
stream := cipher.NewCBCEncrypter(block, iv)
stream.CryptBlocks(ciphertext[block.BlockSize:], plaintext)
return ciphertext, nil
}
crypto/cipher.AEAD 是更安全的选择，但接口更绕
相比裸 AES-CBC，cipher.NewGCM 返回的 AEAD 实例自动处理 IV、认证标签（auth tag），还能防篡改——但它的 Seal 和 Open 方法参数顺序容易搞反，且要求 nonce（即 IV）不能重复。
- nonce 长度由具体算法决定：
GCM要求 12 字节，ChaCha20-Poly1305要求 24 字节 -
Seal(dst, nonce, plaintext, additionalData)中additionalData是可选的未加密元数据（如时间戳），但不能为空切片，得传nil - 解密失败时
Open直接返回nil, cipher.ErrDecrypt，不会泄露错误类型细节
func encryptGCM(plaintext []byte, key []byte) ([]byte, error) {
block, _ := aes.NewCipher(key)
aead, _ := cipher.NewGCM(block)
nonce := make([]byte, aead.NonceSize())
if _, err := rand.Read(nonce); err != nil {
return nil, err
}
return aead.Seal(nonce, nonce, plaintext, nil), nil
}
func decryptGCM(ciphertext []byte, key []byte) ([]byte, error) {
block, := aes.NewCipher(key)
aead, := cipher.NewGCM(block)
nonceSize := aead.NonceSize()
if len(ciphertext) < nonceSize {
return nil, errors.New("ciphertext too short")
}
nonce, ciphertext := ciphertext[:nonceSize], ciphertext[nonceSize:]
return aead.Open(nil, nonce, ciphertext, nil)
}
别碰 crypto/md5 和 crypto/sha1 做密钥派生
MD5/SHA1 已被证明不安全，且它们是哈希不是密钥派生函数（KDF）。用它们对密码做一次哈希当密钥，等于把弱密码直接暴露给暴力破解。
- 正确做法是用
golang.org/x/crypto/pbkdf2或scrypt，指定足够高的迭代次数（PBKDF2 至少 10^6） - 盐（salt）必须随机且唯一，每次加密都换，不能硬编码或复用
- 派生出的密钥长度要匹配 AES 要求：例如 PBKDF2 + SHA256 生成 32 字节密钥用于 AES-256
func deriveKey(password, salt []byte) []byte {
return pbkdf2.Key(password, salt, 1000000, 32, sha256.New)
}
// 使用示例：
salt := make([]byte, 16)
rand.Read(salt)
key := deriveKey([]byte("user-password"), salt)
// 注意：salt 必须和密文一起保存/传输
读写文件时加密容易丢字节或破坏格式
直接对整个文件内容调用 encryptAES 再写入，看似简单，但大文件会吃光内存；流式加密又容易在边界处填充满错，导致解密后末尾多出乱码字节。
本书是全面讲述PHP与MySQL的经典之作，书中不但全面介绍了两种技术的核心特性，还讲解了如何高效地结合这两种技术构建健壮的数据驱动的应用程序。本书涵盖了两种技术新版本中出现的最新特性，书中大量实际的示例和深入的分析均来自于作者在这方面多年的专业经验，可用于解决开发者在实际中所面临的各种挑战。
立即学习“go语言免费学习笔记（深入）”；
- 不要一次性读完整个文件——用
bufio.Reader分块读取，每块单独填充、加密、写入 - 最后一块可能不足块大小，必须按 PKCS#7 规则填充；解密时需从最后一块反向解析真实长度
- 二进制文件（如图片、PDF）加密后仍是二进制，别用
string()强转，否则 UTF-8 解码失败
加密逻辑本身不复杂，真正卡住人的是 IV 管理、填充一致性、密钥来源这三处。随便一个没对齐，解密就返回空或 panic，还查不出哪行错了。
