在 Go 中复用同一个 cipher.BlockMode 解密器（如 CBC 模式下的 CBCDecrypter）会导致后续解密结果错误——仅首次解密正确，后续调用会破坏首块明文，根本原因是 CBC 模式内部状态被意外复用。
在 go 中复用同一个 `cipher.blockmode` 解密器（如 cbc 模式下的 `cbcdecrypter`）会导致后续解密结果错误——仅首次解密正确，后续调用会破坏首块明文，根本原因是 cbc 模式内部状态被意外复用。
CBC（Cipher Block Chaining）是一种带状态的分组密码工作模式：解密时，每个密文块需与前一块的密文（或 IV）进行异或运算才能恢复原始明文。Go 标准库中的 cipher.CBCDecrypter 实现并非纯函数，而是内部维护解密上下文状态——具体而言，它会缓存上一个密文块（用于下一轮异或），以支持流式或分段解密。
在你的代码中，decrypter 是全局变量且在 init() 中一次性初始化：
decrypter = cipher.NewCBCDecrypter(tripleDESChiper, iv)
随后多次调用 decrypter.CryptBlocks(decrypted, hash) 时，解密器将 hash 视为「连续密文流的后续片段」，而非独立消息。第一次调用正常（IV 正确参与首块运算）；但第二次调用时，解密器误把第一次解密的最后一块密文（即 hash 的末尾块）当作本次解密的「前一块密文」，导致首块明文被错误异或，表现为前 16 字节（DES 块长 × 2 = 16 字节，因 Triple DES 块大小仍为 8 字节，但 CBC 操作单位是块，而示例中 iv 取前 8 字节，实际影响首块 8 字节；但输出显示前 16 字节异常，源于 ciphertext[:des.BlockSize] 错误截取了 8 字节作为 IV，而 ciphertext 长度为 16，导致 iv 实际为 "01234567"，但后续逻辑仍受状态污染影响）失真，后续块则因链式依赖保持“稳定错误”。
✅ 正确做法：每次解密都创建全新的解密器实例，确保 IV 和内部状态完全隔离：
func decrypt(hash []byte) []byte {
// 每次解密均重新构建 CBCDecrypter，传入相同 IV
tripleDESChiper, _ := des.NewTripleDESCipher([]byte(tripleKey))
iv := hash[:des.BlockSize] // 注意：此处应使用原始加密时的 IV，而非密文前缀（见下方说明）
decrypter := cipher.NewCBCDecrypter(tripleDESChiper, iv)
decrypted := make([]byte, len(hash))
decrypter.CryptBlocks(decrypted, hash)
return decrypted
}⚠️ 关键注意事项：
- IV 必须与加密时严格一致：示例中 iv := ciphertext[:des.BlockSize] 是危险做法——它复用了密文前缀作为 IV，虽在单次加密/解密中巧合可行，但违背安全实践。正确方式是显式生成并保存随机 IV（如加密前用 crypto/rand.Read(iv)），并将 IV 与密文一同传输（通常前置）。
- 密钥安全性：tripleKey = "12345678asdfghjkzxcvbnmq" 是硬编码弱密钥，生产环境应使用密码学安全的随机密钥（24 字节）。
- 填充处理：DES/Triple DES 要求输入长度为块大小（8 字节）整数倍，需在加密前 PKCS#7 填充，解密后移除。标准库不自动处理，需手动实现。
总结：CBC 模式解密器不是无状态工具，其设计初衷是处理连续数据流（如网络包）。对独立消息解密，必须遵循“一消息一解密器”原则。这一原则同样适用于其他带链式状态的模式（如 CFB、OFB），而 ECB、CTR 等无状态模式则可安全复用。
