Go 中使用 cipher.NewCBCDecrypter 创建的解密器是有状态的，重复调用其 CryptBlocks 方法会因内部 IV 状态被覆盖而破坏 CBC 模式解密逻辑，导致仅首次解密正确，后续调用首 16 字节（即首个分组）错误。
go 中使用 `cipher.newcbcdecrypter` 创建的解密器是**有状态的**，重复调用其 `cryptblocks` 方法会因内部 iv 状态被覆盖而破坏 cbc 模式解密逻辑，导致仅首次解密正确，后续调用首 16 字节（即首个分组）错误。
在 CBC（Cipher Block Chaining）模式下，解密过程严格依赖前一个密文块（或初始化向量 IV）与当前密文块的链式关系：
- 解密第 1 块时，需用原始 IV 异或解密结果；
- 解密第 2 块时，需用第 1 块密文异或解密结果；
- 依此类推。
Go 标准库中的 cipher.BlockMode 实现（如 cbcDecrypter）将 IV 作为可变内部状态维护。每次调用 CryptBlocks 时，它不仅输出明文，还会就地更新内部 IV 缓冲区为当前密文块的值——这是为了支持流式解密（例如解密超长数据时分批次调用）。因此，同一个解密器实例不可重复用于独立消息的解密。
在你的代码中，decrypter 是全局变量且在 init() 中一次性初始化：
decrypter = cipher.NewCBCDecrypter(tripleDESChiper, iv) // iv 被拷贝进内部状态首次调用 decrypt(hash) 时：
- 内部 IV 初始为 “0123456789qwerty” 的前 8 字节（des.BlockSize == 8）；
- 正确解密第 1 块后，内部 IV 被更新为 hash[0:8]（即密文首块）；
- 整个 hash 被完整解密，结果正确。
但第二次调用 decrypt(hash) 时：
- 内部 IV 已不再是原始 IV，而是上一次解密时残留的 hash[0:8]；
- 解密第 1 块时，错误地用 hash[0:8] 异或了 tripleDESChiper.Decrypt 的输出，导致首 8 字节（DES 块大小）完全错误；
- 后续块因依赖前一块密文，虽不受 IV 错误影响，但首块污染已造成整体数据失真（注意：Triple DES 在 CBC 中仍以 8 字节为块单位，但密钥为 24 字节）。
✅ 正确做法：每次解密都创建新的解密器实例，确保 IV 状态纯净。
以下是修复后的关键代码段：
func decrypt(hash []byte) []byte { // 每次解密均重新创建 CBC 解密器，传入原始 IV tripleDESChiper, err := des.NewTripleDESCipher([]byte(tripleKey)) if err != nil { panic(err) } // 注意：此处必须使用与加密时相同的 IV // 示例中 IV 来自 ciphertext 前 8 字节，实际应单独保存/传输 iv := hash[:des.BlockSize] // 或从别处获取原始 IV（更安全的做法） decrypter := cipher.NewCBCDecrypter(tripleDESChiper, iv) decrypted := make([]byte, len(hash)) decrypter.CryptBlocks(decrypted, hash) return decrypted }⚠️ 重要注意事项：
- IV 必须唯一且不可预测：生产环境切勿硬编码或复用 IV。应随机生成（如 crypto/rand.Read），并随密文一同存储或传输。
- 密钥安全性：示例中 tripleKey 是 ASCII 字符串，直接转 []byte 得到 24 字节，符合 Triple DES 要求；但真实场景应使用密码学安全的密钥派生（如 PBKDF2）。
- 填充处理：上述代码未处理 PKCS#7 填充。实际应用中，加密后需填充至块对齐，解密后必须剥离填充（可借助 golang.org/x/crypto/pkcs7）。
- 避免全局加解密器：同理，encrypter 也不应复用——CBC 加密器同样维护内部 IV 状态，重复使用会导致密文不一致。
总结：CBC 模式的核心约束在于其链式依赖性，而 Go 的 cipher.BlockMode 接口将这一状态封装于实例内部。开发者必须明确——每个独立的加/解密操作，都应使用新创建的、携带正确初始参数（密钥+IV）的 BlockMode 实例。忽视此原则，是 CBC 类算法在 Go 中最常见且隐蔽的误用陷阱。