不能用os.writefile直接处理加密后数据，因其虽支持[]byte写入，但无法满足iv/密文绑定、块对齐、避免截断等加解密流必需的精确控制要求；必须用os.openfile+write分步写入iv和密文。
加密后数据直接写入文件，为什么不能用 os.WriteFile 简单处理？
因为 os.WriteFile 会把原始字节原样落盘，而加密后的数据（尤其是使用 AES-CBC、AES-GCM 等模式）通常包含非 UTF-8 兼容的二进制内容（如 IV、密文、认证标签），如果中间误经字符串转码（比如先转 string 再写），可能触发非法 UTF-8 替换（如 \ufffd），导致解密失败。
实操建议：
- 始终以
[]byte形式操作加密结果，避免任何隐式string转换 - 写入前确认加密输出是纯二进制切片——检查是否含
\x00、高位字节等典型非文本特征 - 若用
os.WriteFile，传入原始[]byte即可；但更推荐用os.OpenFile+Write，便于后续追加 IV 或元数据
如何安全地把 IV 和密文一起写入同一个文件？
IV 不可复用，必须每次随机生成并和密文绑定存储。常见错误是分开存、或硬编码 IV，导致无法解密或安全性归零。
实操建议：
- 用
cipher.NewGCM时，IV 长度由算法决定（如 AES-GCM 推荐 12 字节），调用rand.Read(iv)生成，不要自己拼接或截断 - 写入顺序固定：先写 IV（固定长度头），再写密文。例如：
file.Write(iv); file.Write(ciphertext) - 不要 base64 编码后再写——增加体积且无必要；文件本就是二进制载体
- 若需兼容性（如跨平台读取），在头部加 4 字节长度标记（如 IV 长度），但 GCM 场景下通常固定 12 字节，可省略
用 AES-GCM 加密后写文件，为什么解密总报 cipher: message authentication failed？
这个错误几乎全是写入/读取不一致导致的：要么 IV 没读全，要么密文被截断，要么额外写了 BOM 或换行符。
实操建议：
- 读取时严格按写入顺序还原：先读固定长度 IV（如 12 字节），再读剩余全部为密文 —— 用
io.ReadFull而非Read - 检查文件是否被文本编辑器意外打开并保存（会插入 BOM 或换行），用
xxd yourfile.bin | head确认开头确实是原始 IV 字节 - GCM 的
Seal输出包含密文+认证标签，长度 = 明文长度 + 16；写入时必须写完整，不能只写前 N 字节 - 密钥和 IV 必须完全一致；调试时可打印
fmt.Printf("%x", iv)对比读写两端
性能敏感场景下，该用 bufio.Writer 吗？
对小文件（bufio.Writer 可减少 write(2) 次数。
实操建议：
- 启用缓冲：用
bufio.NewWriterSize(file, 64*1024)（64KB 常见值），最后别忘Flush() - 不要对加密流再套
gzip或其他压缩——密文近似随机，压缩率极低，纯增 CPU 开销 - 若需原子写入（防中断损坏），先写临时文件，再
os.Rename替换原文件；注意Rename在 Windows 上跨盘会失败
最易被忽略的是：加密写入不是“写字符串”，而是精确控制二进制布局。哪怕多写一个字节、少读两个字节，解密就必然失败——没有模糊空间。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
