本文详解vb.net与go语言间aes加密结果不一致的根本原因，聚焦cbc与cfb模式差异、pkcs#7填充缺失、utf-8字节序列处理及iv/key编码统一等关键问题，提供可验证的跨语言互通实现方案。
本文详解vb.net与go语言间aes加密结果不一致的根本原因，聚焦cbc与cfb模式差异、pkcs#7填充缺失、utf-8字节序列处理及iv/key编码统一等关键问题，提供可验证的跨语言互通实现方案。
在将VB.NET加密逻辑迁移到Go时，出现“VB输出固定32字节密文而Go返回变长十六进制字符串”的现象，本质并非长度计算错误，而是算法参数未对齐导致的语义级不兼容。核心矛盾集中在三点：加密模式（Mode）、填充机制（Padding）和原始数据编码（Encoding）。下面逐层解析并给出生产级解决方案。
? 1. 模式必须严格一致：CBC ≠ CFB
VB.NET AesManaged 默认使用 CBC（Cipher Block Chaining）模式，而你的Go代码调用的是 cipher.NewCFBEncrypter —— 这是完全不同的流式加密模式。CFB无需填充、按字节/字操作，而CBC是分组模式（块大小16字节），要求输入长度为16的整数倍。二者数学原理不同，输出不可互换。
✅ 正确做法：Go中改用 cipher.NewCBCEncrypter，并确保IV长度恒为16字节（AES块大小）：
func EncryptCBC(key, plaintext string, iv []byte) []byte {
block, _ := aes.NewCipher([]byte(key))
if len(iv) != block.BlockSize() {
panic("IV length must be 16 for AES")
}
// PKCS#7 填充（关键！）
padded := pkcs7Pad([]byte(plaintext), block.BlockSize())
ciphertext := make([]byte, len(padded))
mode := cipher.NewCBCEncrypter(block, iv)
mode.CryptBlocks(ciphertext, padded)
return ciphertext
}
func pkcs7Pad(data []byte, blockSize int) []byte {
padding := blockSize - len(data)%blockSize
padtext := make([]byte, padding)
for i := range padtext {
padtext[i] = byte(padding)
}
return append(data, padtext...)
}⚠️ 注意：
AesManaged在 .NET Framework 中默认启用 PKCS#7 填充（PaddingMode.PKCS7），且不可禁用；若VB.NET代码未显式设置.Padding = PaddingMode.None，则Go端必须实现同等填充逻辑，否则解密必然失败。立即学习“go语言免费学习笔记（深入）”；
? 2. 字符串编码必须显式统一：ANSI ≠ UTF-8 ≠ raw bytes
VB.NET中 StreamWriter.Write(source) 默认使用 UTF-8 编码写入流（除非显式指定 Encoding.Default 即系统ANSI），而Go中 []byte(plaintext) 是UTF-8字节序列——看似一致，实则隐患暗藏：
- 若VB.NET项目编译时未设置
<propertygroup><defaultencoding>utf-8</defaultencoding></propertygroup>，StreamWriter可能回退至系统本地编码（如Windows-1252）； - 更稳妥的方式是在VB.NET中显式指定UTF-8：
Using streamWriter As New StreamWriter(cryptoStream, System.Text.Encoding.UTF8)
streamWriter.Write(source)
End UsingGo端保持 []byte(plaintext) 即可（Go字符串底层即UTF-8字节序列）。
? 3. IV与Key的传递必须字节级精准
你代码中硬编码了IV（[]byte{178,212,...}），但需确认VB.NET中使用的IV是否完全相同字节序列。常见陷阱：
- VB.NET中IV常以Base64字符串传入：
Convert.FromBase64String("si3U...")； - Go中若用字符串
"si3U..."再[]byte()会得到ASCII字节而非解码后二进制，应使用base64.StdEncoding.DecodeString()； - Key同理：16/24/32字节对应AES-128/192/256，绝不能直接
[]byte("mykey123")——这只有8字节！
✅ 推荐安全Key/IV生成方式（两端一致）：
// 生成16字节随机IV（每次加密唯一） iv := make([]byte, 16) rand.Read(iv) // Key建议用PBKDF2从口令派生，或直接使用32字节随机密钥
✅ 完整互通验证示例（VB.NET + Go）
| 项目 | VB.NET 端 | Go 端 |
|---|---|---|
| Key | Encoding.UTF8.GetBytes("32-byte-key-for-aes256-123456789012") |
[]byte("32-byte-key-for-aes256-123456789012") |
| IV |
New Byte(15) {0,1,2,...,15} （16字节） |
[]byte{0,1,2,...,15} |
| Mode | aesManaged.Mode = CipherMode.CBC |
cipher.NewCBCEncrypter(...) |
| Padding | aesManaged.Padding = PaddingMode.PKCS7 |
pkcs7Pad(...) 手动实现 |
| Encoding | StreamWriter(..., UTF8) |
[]byte(plaintext) |
执行后，VB.NET ToArray().Length 与 Go len(EncryptCBC(...)) 将严格一致（为 (len(plaintext)+1)/16*16），且Base64编码后的字符串可双向解密。
? 总结：跨语言AES互通三原则
- 模式对齐：明确指定并统一使用 CBC（推荐）或 GCM（更安全），杜绝CFB/ECB等非默认模式；
- 填充显式：VB.NET默认PKCS#7 → Go必须手动实现，不可依赖“无填充”假设；
- 字节为本：所有Key、IV、明文均以原始字节数组参与运算，字符串仅作传输载体，编码转换必须显式可控。
遗留系统升级不是重写，而是精准对接。当VB.NET与Go的AES输出终于对齐那32字节时，你接住的不仅是一段密文，更是跨越二十年技术代沟的信任链。
