xor不是加密而是掩码，无法保护文件；必须用aes-gcm等方案。它线性可逆、无扩散，易被已知明文攻击，且go中string转换会破坏字节；仅适用于临时混淆，密钥须为[]byte并循环使用。
别用XOR加密文件——它根本不是加密，只是掩码；真要保护文件内容，必须用AES-GCM或类似方案。
为什么xorEncryptDecrypt函数不能用于文件加密
常见错误现象：file.enc用xxd查看时，仍能肉眼识别%PDF、PK\x03\x04等签名；解密后文件损坏，尤其含二进制数据时。
- XOR是线性、可逆、无扩散的位运算，攻击者只要拿到一段明文（比如ZIP头）+对应密文，立刻反推密钥片段
- 密钥若短于文件（如单字节
[]byte{0x42}），会暴露周期性，等价于凯撒密码 - Go中
string隐含UTF-8语义，直接把[]byte转string再传给字符串版xorEncryptDecrypt，非法字节会被静默替换成\uFFFD，解密后不可恢复
如果坚持要用XOR做轻量级混淆，必须全程操作[]byte
使用场景：临时脱敏日志片段、调试阶段掩码配置值、嵌入式固件里简单混淆资源数据。
- 密钥必须是
[]byte，不能是string；读取方式推荐os.Getenv("XOR_KEY")后转[]byte(keyStr) - 循环密钥：对每个字节执行
data[i] ^= key[i%len(key)]，避免硬编码或固定偏移 - 超大文件（>1GB）禁止用
ioutil.ReadFile一次性加载；改用bufio.NewReader分块读取 → 分块异或 → 分块写入 - 不处理文件头/尾校验、不保证完整性，也不防篡改——它只负责“让肉眼看不出明文”
garble build -literals才是Go源码里真正安全的字符串保护方式
常见错误现象：自己写脚本对.go文件做正则替换变量名，结果go test全挂、CGO崩溃、IDE跳转失效。
-
garble不修改源码，而是在编译期把字符串字面量（如"api_key"）加密成常量，运行时再解密到内存 - 必须用
garble build -literals，不能先garble再go build——后者完全绕过加密逻辑 - 全局
const key = "xxx"不会被处理，需手动改成var key string+ 初始化函数 - CI中复现结果必须加
-seed=12345，否则每次混淆名不同，无法审计或回滚
配置文件加密必须走AES-GCM，且解密后才能喂给viper
常见错误现象：viper.ReadInConfig()报错invalid character '\x00' looking for beginning of value。
- 密文格式必须包含三段：
nonce（通常12字节前置）、密文主体、auth tag（末尾16字节） - 密钥必须是32字节（AES-256），严禁硬编码；推荐从环境变量base64解码获取
- 解密后得到明文
[]byte，再调用viper.ReadConfig(bytes.NewReader(decrypted)) - 不要写wrapper函数patch
viper.ReadInConfig——它内部有缓存和重载机制，patch后容易漏reload或panic
最易被忽略的一点：所有混淆和加密手段，都解决不了密钥管理问题。密钥一旦泄露，XOR和AES-GCM同样失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
