aes-256-cbc单次加密1mb数据性能损耗极低，主要瓶颈在于i/o组织、填充处理、密钥派生和缓冲策略，而非aes算法本身。
Go 处理文件加解密的性能损耗，主要不在 AES 本身，而在于你如何组织 I/O、填充、密钥派生和缓冲——AES-256-CBC 在现代 CPU 上单次加密 1MB 数据通常
大文件流式加解密必须分块对齐，不能直接用 io.Copy
常见错误是把 os.OpenFile 和加密 writer 直接套进 io.Copy。AES 是分组密码（块大小固定为 16 字节），io.Copy 不保证每次读取长度是 16 的倍数，最后一块可能被截断，导致填充错乱、解密失败或 panic。
- 读取缓冲区大小必须设为 16 的倍数（如
65536），避免跨块截断 - 每块读出后，先做 PKCS#7 填充（仅对最后一块显式填充，中间块不用）
- 加密后写入目标文件前，要确保整块（含填充）写满，不能依赖
io.ReadFull报错就终止 - 小文件（[]byte 处理；大文件必须流式，但逻辑仍是“读一块 → 填充 → 加密 → 写一块”
scrypt.Key 是性能瓶颈，不是 aes.NewCipher
实际压测中，对 100MB 文件做 AES-256-CBC 加密，密钥派生（scrypt.Key）平均耗时占总时间 60% 以上，而 AES 加密本身不到 15%。这是因为 scrypt 故意设计为高内存/计算成本，防止暴力破解。
- 参数
N=32768, r=8, p=1是安全与性能平衡点，别擅自调低N（比如降到 1024）来“提速”，那等于自废防御 - 如果业务允许，把密钥预生成并存入外部 KMS（如 HashiCorp Vault），跳过每次加解密都调
scrypt.Key - 绝对不要用
sha256.Sum256替代scrypt.Key——它快 100 倍，但安全性归零
IV 和 salt 必须随机且随文存储，复用会导致性能假象
有人测试发现“固定 IV + 固定 salt”时加解密快了 20%，但这只是缓存友好带来的假象，实际已完全破坏语义安全：相同明文永远生成相同密文，攻击者可轻易识别重复数据模式甚至重放篡改。
- 每次加密必须调用
crypto/rand.Read生成新IV（16 字节）和新salt（建议 32 字节） - 写入文件时顺序固定：
salt（32B）→IV（16B）→ 密文；解密端严格按此偏移读取 - 硬编码或从环境变量读 IV/salt 是严重错误，哪怕只用于测试
真正影响落地性能的，从来不是 AES 实现有多快，而是你有没有在密钥派生上妥协、有没有让流式边界对齐、有没有把 salt/IV 当成可复用的配置项——这些地方一松动，性能数字再好看也没意义。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
