使用 crypto/aes 加密前必须生成随机 IV（16 字节）并配合 PKCS#7 填充，密钥需通过 scrypt 从密码派生，salt 和 IV 需随密文存储，解密须校验填充或 HMAC 防乱码。
用 crypto/aes 做对称加密前必须处理 IV 和填充
Go 标准库不提供开箱即用的“加密文件”函数，aes.NewCipher 只生成密钥对象，真正加密需要自己组合 cipher.BlockMode（如 cipher.NewCBCEncrypter）并手动管理 IV。常见错误是复用固定 IV（比如全 0），这会导致相同明文生成相同密文，严重削弱安全性。
必须为每次加密生成随机 IV，并和密文一起保存（通常前置在文件开头）。解密时先读出 IV，再用它初始化解密模式。同时，AES 是分组密码（16 字节块），明文长度不是 16 的倍数时需填充（PKCS#7 最常用），crypto/cipher 不自动处理，得自己加。
- IV 长度必须等于 AES 块大小（16 字节），用
crypto/rand.Read生成 - 填充逻辑要严格：末尾补 N 个字节，值都为 N；解密后校验并移除
- 不要把密钥或 IV 硬编码在代码里，应通过环境变量或密钥管理服务注入
os.OpenFile + io.Copy 不能直接加密大文件流
想边读边加密、避免内存爆掉？别直接套 io.Copy。AES 加密模式（如 CBC）要求数据按块处理且依赖前一块密文，而 io.Copy 没有块对齐保障，容易导致最后一块填充错乱或解密失败。
正确做法是用缓冲区（如 64KB）分块读取，对每块做完整加解密流程（含填充/去填充），再写入目标文件。小文件可一次性读进 []byte 处理；大文件必须流式分块，但每块边界要对齐到 16 字节（填充后）。
立即学习“go语言免费学习笔记（深入）”；
- 读取缓冲区大小建议设为 16 的倍数（如 65536），避免跨块截断
- 最后一块必须显式填充，不能依赖
io.ReadFull报错就终止 - 写入时先写 IV（16 字节），再写密文，解密端严格按此顺序读
用 golang.org/x/crypto/scrypt 衍生密钥比硬套密码更安全
用户给的原始密码（如 "mypass123"）不能直接当 AES 密钥用——太短、熵低、易被暴力破解。必须用密钥派生函数（KDF）扩展成 32 字节密钥（AES-256）。标准库没提供 scrypt 或 bcrypt，得引入 golang.org/x/crypto/scrypt。
scrypt.Key 的参数很关键：N=32768（CPU/内存成本）、r=8（内存块大小）、p=1（并行度）是较稳妥起点。盐值（salt）必须随机且唯一，和 IV 一样存进输出文件头部（比如前 32 字节放 salt，接着 16 字节 IV，再密文）。
- 盐值不能复用，每次加密都调用
crypto/rand.Read生成新 salt - 避免用
sha256.Sum256这类快速哈希代替 KDF，它们无法抵抗 GPU 暴力破解 - 如果业务允许，优先用外部密钥管理（如 HashiCorp Vault），而非本地派生
解密失败时 cipher.NewCBCDecrypter 不报错，但结果全是乱码
AES-CBC 解密过程本身不会 panic 或返回 error，哪怕密钥错、IV 错、密文损坏，它只是默默输出一堆无效字节。你得靠后续逻辑发现异常：比如去填充时发现末尾字节超出范围（>16），或解密后字符串包含大量非法 UTF-8，或 JSON/XML 解析失败。
因此必须设计验证机制。最简单的是加密前计算明文 h := sha256.Sum256，连同 IV/salt 一起加密，解密后重新算哈希比对；更规范的做法是在加密流程末尾追加 HMAC（用另一个密钥），解密后先验签再解包。
- 不要依赖“解密后能
string()就成功”，二进制文件或含控制字符的文本会误判 - HMAC 密钥绝不能和 AES 密钥相同，建议用 KDF 分别派生两个子密钥
- 错误提示别暴露细节（如“IV 错误”），统一返回“解密失败”，防侧信道攻击
