go 文件 aes 加密应使用 crypto/cipher 封装而非直接调用 crypto/aes，需随机 iv（前置存储）、pkcs#7 填充（手动实现）、分块流式加解密（如 ctr），禁用 ecb，注意文件权限（0600）、io.copy 陷阱及路径校验。
Go 里用 AES 加密文件，别直接套 crypto/aes 原生块模式
Go 标准库的 crypto/aes 只提供底层分组密码，不带填充、不带模式封装。直接拿 aes.NewCipher + cipher.NewCBCEncrypter 写文件加密，大概率解出来是乱码或 panic。
真正该用的是 crypto/cipher 包里的封装类型，配合明确的初始化向量（IV）和 PKCS#7 填充——但标准库没直接提供填充函数，得自己补。
-
iv必须随机生成且随密文一起保存（通常前置 16 字节），不能硬编码或复用 - 文件太大时别一次性读进内存：用
bufio.Reader分块读 +cipher.Stream流式加解密（如cipher.NewCTR）更安全 - 别用 ECB 模式，哪怕只是测试——它会让相同明文块产生相同密文块，图片加密后还能看出轮廓
os.OpenFile 和 io.Copy 配合加密流时的权限与缓冲陷阱
写加密结果到新文件时，os.OpenFile(path, os.O_CREATE|os.O_WRONLY, 0600) 的权限掩码必须显式设为 0600，否则默认可能是 0666，导致密文文件被同组用户读取。
用 io.Copy 管道数据时，如果加密流是 cipher.Stream 类型（如 CTR），它不实现 io.ReaderFrom，io.Copy 会退化成小 buffer 循环，性能差还容易漏写最后不足 buffer 大小的数据块。
立即学习“go语言免费学习笔记（深入）”；
- 改用
io.CopyN或手动Read/Write循环，确保最后一块也被处理 - 加密前先
stat源文件，避免对目录或符号链接误操作；解密时检查目标路径是否已存在，防止覆盖 - 大文件建议用
bufio.NewWriterSize(f, 1 设置 1MB 缓冲，减少系统调用次数
密钥从哪来？别用字符串字面量硬编码 password
直接把 "my-secret-key-123" 当 AES-256 密钥用，长度不对（AES-256 要 32 字节），Go 会 panic：crypto/aes: invalid key size 17。更糟的是，用户输的密码通常不是合法密钥。
必须走密钥派生：用 golang.org/x/crypto/pbkdf2 或 scrypt，配合盐值（salt）和足够迭代轮数。盐值要随机生成、随密文存储（比如放在 IV 后面或单独 header）。
- 迭代次数至少
100000，盐长不少于 16 字节 - 别用 MD5 或 SHA1 做派生——
pbkdf2.Key要指定sha256.New之类 - 如果工具支持命令行输密码，记得用
golang.org/x/term.ReadPassword关闭回显
解密失败时常见的 crypto/cipher: message authentication failed
这个错误基本等于“密钥或 IV 不对”，但新手常以为是代码逻辑问题。AES-GCM 模式下，它其实是认证失败（authentication tag 校验不通过），不是解密出错。
如果你用 GCM（推荐），tag 必须和密文一起保存（通常追加在末尾），解密时要截取出来传给 Seal / Open 方法。少一个字节、顺序颠倒、用了加密时的 IV 去解密——全都会触发这个错误。
- GCM 的
Nonce（即 IV）不能重复，也不能用计数器简单递增（易预测），建议每次随机 12 字节 - 不要自己拼接 IV + 密文 + tag：用固定格式 header（如 4 字节长度 + IV + 密文 + tag），否则解析容易错位
- 解密前先检查文件大小是否 ≥ IV 长度 + tag 长度（GCM 默认 16 字节），避免 panic
加解密不是拼函数，是管住 IV、盐、tag、缓冲、权限这五根线。少盯一眼，文件就可能永远打不开。
