企业官网建设流程全解析

刚接到一个联调需求：前端Vue项目里用CryptoJS做AES加密，后端C#负责解密。这种跨语言加密通信在前后端分离的项目里很常见，尤其是接口有防重放、防篡改、敏感字段保护要求的时候。但很多朋友卡在第一步——前端加密出来的字符串，后端拿RijndaelManaged或Aes一解就报错，不是wrong algorithm就是Padding is invalid and cannot be removed。这篇文章把我实际联调的经验完整写出来，从算法参数对齐、前端加密封装、C#后端解密，到报错排查和升级建议，一步到位。

1. 整体设计思路：为什么选AES，参数对齐才是核心

1.1 这到底解决什么问题

前后端分离架构下，接口跑在公网或半信任网络上，请求体里的手机号、身份证、订单金额等敏感字段直接明文传输，很容易被中间人抓包或从浏览器DevTools里看到。AES（Advanced Encryption Standard）是一种对称加密算法，加解密用同一把密钥，性能高、实现成熟，非常适合服务端与客户端之间批量加密数据。Vue前端用CryptoJS库做AES加密，后端C#用内置加密类解密，是很多团队采用的方案。

但AES本身只是算法标准，真正决定“能不能解开”的是一整套参数组合：密钥长度、工作模式、填充方式、初始向量IV、字符编码、输出格式。前端CryptoJS和C#的加密类在概念上基本一致，但默认值不一样。比如CryptoJS的AES.encrypt不传mode时默认是CBC，不传padding时默认是Pkcs7；而C#的RijndaelManaged默认是CBC + PKCS7，Aes类默认也是CBC，但密钥和IV的长度需要显式指定。这些默认值看似相同，但一旦有一方显式配置搞错，就会导致解密失败。

1.2 把加解密参数当成接口协议来设计

我在实际项目中，会把“加密算法、密钥长度、模式、填充、IV、密文编码”这六项明文写进接口文档里，作为前后端共同遵守的协议。缺了任何一项，后面就是互相甩锅的联调地狱。

1.3 密钥怎么管理：至少别写死在代码里

前端代码本身是暴露在浏览器里的，把AES密钥硬编码在Vue项目里，实际上只是“防君子不防小人”。但很多业务场景下，这个加密是用来防“普通抓包用户”和“不小心在日志里打印明文”的情况，而不是防专业逆向。所以方案上可以做分层：

• 第一层：前端build时通过环境变量注入密钥，不要直接写死在源码里；
• 第二层：如果业务允许，接口走HTTPS，AES加密作为纵深防御；
• 第三层：高频接口可以使用动态密钥，密钥由后端下发或用双方约定的密钥协商机制生成，但这会增加复杂度。

我们的核心目标是先把CryptoJS和C#的加解密跑通，后面再谈怎么藏密钥。下面直接进入可运行的代码。

2. 前端Vue + CryptoJS实现AES加密

2.1 安装CryptoJS并封装加密模块

在Vue 2或Vue 3项目里，通过npm安装CryptoJS：

npm install crypto-js

然后我在src/utils/crypto.js里做了统一封装，方便所有接口复用。封装思路是：把密钥和IV集中管理，提供encrypt和decrypt两个方法，对外只处理字符串和JSON对象，调用方不需要关心CryptoJS的WordArray类型。

import CryptoJS from 'crypto-js' // 线上环境请通过环境变量注入，别写死在这里 const KEY = CryptoJS.enc.Utf8.parse('your-32-byte-secret-key-here!!') const IV = CryptoJS.enc.Utf8.parse('your-16-byte-iv!!') // 加密：支持字符串或对象 export function aesEncrypt(plainText) { if (plainText && typeof plainText === 'object') { plainText = JSON.stringify(plainText) } const encrypted = CryptoJS.AES.encrypt(plainText, KEY, { iv: IV, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }) return encrypted.toString() } // 解密：返回字符串 export function aesDecrypt(cipherText) { const decrypted = CryptoJS.AES.decrypt(cipherText, KEY, { iv: IV, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }) return CryptoJS.enc.Utf8.stringify(decrypted) }

这里有几个细节要特别说明：

• 密钥和IV都用CryptoJS.enc.Utf8.parse转成WordArray，这样和C#端直接用UTF-8取字节是完全一致的；
• encrypted.toString()默认输出Base64字符串，C#端方便处理；
• 如果plainText是数字、布尔值，最好先统一转成字符串再加密，否则CryptoJS内部会做隐式转换，容易和后端反序列化对不上。

2.2 在Axios请求拦截器里接入加密

为了不侵入业务代码，我在Axios的请求拦截器里做全局加密：前端页面上正常提交对象，拦截器把整个请求体转JSON再加密，后端解密后再处理。这样业务层代码完全无感知。

// request.js import axios from 'axios' import { aesEncrypt, aesDecrypt } from '@/utils/crypto' const service = axios.create({ baseURL: '/api', timeout: 15000 }) service.interceptors.request.use(config => { if (config.data && !config.data._noEncrypt) { config.data = { // 用固定字段包一层，后端根据字段名识别加密内容 payload: aesEncrypt(config.data), _encrypted: true } } return config }, error => Promise.reject(error)) service.interceptors.response.use(response => { const res = response.data if (res._encrypted) { const decryptedStr = aesDecrypt(res.payload) try { return JSON.parse(decryptedStr) } catch (e) { return decryptedStr } } return res }, error => Promise.reject(error))

这里我为什么用payload字段包一层？因为如果只对JSON字符串加密，后端需要知道哪些字段是密文，比较麻烦。统一约定一个字段名，C#后端直接取这个字段做解密，其他逻辑保持不变。_noEncrypt是白名单标记，某些不需要加密的接口（比如文件流上传）可以跳过。

2.3 ECB模式和CBC模式的区别，前端怎么写

有些团队为了省事，会用ECB模式，因为不需要IV。ECB模式下前端代码只需要去掉iv参数：

export function aesEncryptECB(plainText) { if (plainText && typeof plainText === 'object') { plainText = JSON.stringify(plainText) } const encrypted = CryptoJS.AES.encrypt(plainText, KEY, { mode: CryptoJS.mode.ECB, padding: CryptoJS.pad.Pkcs7 }) return encrypted.toString() }

ECB的优点是简单、同一个明文块加密结果永远一样，方便定位问题；缺点也是这个——相同的明文会产生相同的密文，容易泄露数据模式，安全性弱于CBC。AES-ECB在行业里一般不太建议用于传输敏感数据，但内部工具、配置文件加密或联调测试场景仍然大量存在。

我的建议是：如果后端还没实现，直接用CBC；如果后端已经用ECB写死了，前端就按ECB对齐。联调的首要目标是跑通，安全升级可以分阶段走。ECB模式下C#端不需要设置IV，但密钥长度和填充照样要对齐。

2.4 加密对象里混着数组、嵌套结构怎么办

我在实际项目里遇到过，直接用JSON.stringify加密整个对象，如果对象里有null、undefined、函数这些，序列化结果会和后端预期不一致。比如{ name: '张三', age: null }，C#端反序列化成age为0，而前端预期是null，判断逻辑就会出问题。

解决思路是：传给aesEncrypt之前，先对业务对象做一层显式序列化，并且约定好字段类型。比如：

const bizData = { mobile: form.mobile.trim(), amount: Number(form.amount), timestamp: Date.now() } const encryptedPayload = aesEncrypt(bizData)

还有一个容易踩的坑：undefined字段在JSON.stringify里会被直接丢弃，但C#端模型如果定义了对应属性，反序列化以后拿到的是默认值。如果这个默认值会影响业务逻辑，就需要前后端明确空值字段的序列化策略，比如统一转成null或空字符串。

3. 后端C#解密完整实现

3.1 最稳的C#解密方法（.NET Core / .NET 6+）

C#端解密建议用.NET Core时代推荐的Aes类，而不是老的RijndaelManaged。Aes类更语义化，参数配置也更直观。下面这段代码可以直接用在ASP.NET Core的控制器、过滤器或自定义中间件里。

using System.Security.Cryptography; using System.Text; public static class AesHelper { // 必须和前端保持一致：32字节密钥 + 16字节IV private static readonly byte[] Key = Encoding.UTF8.GetBytes("your-32-byte-secret-key-here!!"); private static readonly byte[] Iv = Encoding.UTF8.GetBytes("your-16-byte-iv!!"); public static string Decrypt(string cipherText) { if (string.IsNullOrWhiteSpace(cipherText)) { return string.Empty; } // 前端CryptoJS输出的Base64密文，先转回字节数组 byte[] cipherBytes = Convert.FromBase64String(cipherText); byte[] plainBytes; using (var aes = Aes.Create()) { aes.Key = Key; aes.IV = Iv; aes.Mode = CipherMode.CBC; aes.Padding = PaddingMode.PKCS7; // ICryptoTransform用于执行解密 using (var decryptor = aes.CreateDecryptor(aes.Key, aes.IV)) using (var ms = new MemoryStream(cipherBytes)) using (var cs = new CryptoStream(ms, decryptor, CryptoStreamMode.Read)) using (var sr = new StreamReader(cs, Encoding.UTF8)) { return sr.ReadToEnd(); } } } public static string Encrypt(string plainText) { byte[] plainBytes = Encoding.UTF8.GetBytes(plainText); using (var aes = Aes.Create()) { aes.Key = Key; aes.IV = Iv; aes.Mode = CipherMode.CBC; aes.Padding = PaddingMode.PKCS7; using (var encryptor = aes.CreateEncryptor(aes.Key, aes.IV)) using (var ms = new MemoryStream()) using (var cs = new CryptoStream(ms, encryptor, CryptoStreamMode.Write)) { cs.Write(plainBytes, 0, plainBytes.Length); cs.FlushFinalBlock(); byte[] cipherBytes = ms.ToArray(); return Convert.ToBase64String(cipherBytes); } } } }

这段代码的关键点：

• Convert.FromBase64String对应前端encrypted.toString()的Base64输出；
• Encoding.UTF8.GetBytes对应前端CryptoJS.enc.Utf8.parse，保证密钥字节一致；
• Aes.Create()在.NET里会创建Aes算法的实例，默认Key长度支持128/192/256位，但如果你传入的Key长度不对，会抛CryptographicException，所以密钥串长度必须精确匹配。

3.2 在API控制器里接住加密请求

假设前端请求体是：

{ "payload": "3aBx...Base64密文...", "_encrypted": true }

控制器里可以这样处理：

[HttpPost("order/create")] public async Task<IActionResult> CreateOrder([FromBody] EncryptedRequest request) { // 解密得到JSON字符串 string json = AesHelper.Decrypt(request.Payload); // 反序列化成业务模型 var orderDto = JsonSerializer.Deserialize<CreateOrderDto>(json); // 业务处理... var result = new { orderId = "123456" }; // 如果响应也需要加密，统一返回加密串 var responseJson = JsonSerializer.Serialize(result); return Ok(new { payload = AesHelper.Encrypt(responseJson), _encrypted = true }); } public class EncryptedRequest { public string Payload { get; set; } public bool Encrypted { get; set; } }

我一般把“解密 + 反序列化”封装成一个泛型方法，减少每个接口的样板代码：

public static T DecryptTo<T>(string cipherText) where T : class, new() { string json = Decrypt(cipherText); if (string.IsNullOrWhiteSpace(json)) { return new T(); } return JsonSerializer.Deserialize<T>(json, new JsonSerializerOptions { PropertyNameCaseInsensitive = true }) ?? new T(); }

调用时就是：

var orderDto = AesHelper.DecryptTo<CreateOrderDto>(request.Payload);

注意：C#端的JSON反序列化是区分大小写不敏感的，默认配置下mobile和Mobile能对上，但嵌套对象、枚举类型、日期格式这些还是要提前约定好，否则解密成功也可能死在反序列化阶段。

3.3 老项目用RijndaelManaged怎么写

有些老项目还在用.NET Framework，没有Aes类，只能用RijndaelManaged。写法上很接近，但有几个差异：

• RijndaelManaged支持更多分组长度，而AES标准固定128位块；
• RijndaelManaged的KeySize如果不显式设置，可能出现“密钥长度正确但算法实例行为不一致”的问题；
• Aes类本质上是RijndaelManaged的一个特化封装（128位块 + 指定密钥长度），所以两者写出来效果基本一致。

老代码示例：

using (var rijndael = new RijndaelManaged()) { rijndael.Key = Key; rijndael.IV = Iv; rijndael.Mode = CipherMode.CBC; rijndael.Padding = PaddingMode.PKCS7; // 如果不放心，可以显式设置块大小 rijndael.BlockSize = 128; // 解密逻辑同一个模板... }

我在实际迁移时，会尽量把老项目改成Aes.Create()，因为RijndaelManaged在部分平台上有兼容性提示，新代码不建议用了。如果公司代码库历史包袱太重，暂时改不动，也至少把BlockSize = 128显式写上，避免默认值带来的隐患。

4. 实操踩坑记录：报错排查与对齐细节

4.1 InvalidKeyException: wrong algorithm: AES or Rijndael required

这个报错写法很Java，但C#联调时也会遇到类似情况：你给Aes类或RijndaelManaged设置Key的时候，密钥字节长度不对。AES-128需要16字节密钥，AES-192需要24字节，AES-256需要32字节。如果前端使用32字节密钥串，但C#端不小心用了16字节的Key，就会抛出CryptographicException，提示“指定的密钥大小对此算法无效”之类的错误。

排查方法：

• 前端打印KEY.toString()和IV.toString()，确认字符串内容；
• C#端打印Encoding.UTF8.GetBytes(KEY).Length，确认字节长度；
• 最容易错的是中文字符——密钥里如果包含中文，UTF-8编码下每个汉字占3字节，名义上“16个字符”可能变成“48个字节”，绝对不能用。

我给团队定的规约是：密钥只用大小写字母、数字和英文符号，比如AesKey2024@Dev#ForVue!1234567890，长度控制在32字节，IV用16字节的英文字母数字组合。这样前端和后端都不会因为编码差异翻车。

4.2 Padding is invalid and cannot be removed

这个报错几乎每个做CryptoJS和C#联调的人都遇到过。原因基本集中在以下几类：

尤其要注意+号问题。前端生成Base64密文后，如果通过GET请求参数传递，+会被浏览器解析成空格，后端拿到错误的Base64，解码出来的字节直接错位。我都是统一用POST + JSON body传输密文，这样Base64字符串不会被URL编码破坏。如果实在要放URL参数里，先做encodeURIComponent，后端再Uri.UnescapeDataString。

4.3 CryptoJS版本差异和浏览器兼容性

CryptoJS在npm上的版本还停留在3.x，但社区有4.x的分支。不同版本对CryptoJS.enc.Utf8.parse和CryptoJS.AES.encrypt的行为基本一致，但个别情况下，encrypted.toString()传参不带编码时默认输出Base64，老版本可能对无填充的数据输出行为略有不同。

浏览器兼容性方面，现代浏览器都不需要担心CryptoJS的兼容问题，但有一个隐患：CryptoJS依赖Math.random生成某些内部向量，如果你自己没提供IV，它默认会生成随机IV并拼到密文里，导致每次加密结果不同。这本身是安全的，但也意味着前后端如果没约定IV，C#端解密时压根拿不到CryptoJS生成的随机IV，必挂无疑。所以用CBC模式时，IV必须前后端显式约定，不能用CryptoJS自动生成的随机IV。

4.4 常见问题速查表

4.5 一个完整的联调自测流程

我最怕的是一上来就跨团队联调，双方都认为自己代码没问题。所以我自己会做一套联调自测顺序：

1. 前端本地生成一条密文，把明文和密文都贴在调试文档里；
2. 用一个在线的AES解密工具（选CBC、Pkcs7、UTF-8、Base64）先验证密文能解回明文；
3. 用本地写的C#小控制台程序，把前端密文粘进去解密；
4. 都通了以后，再前后端一起联调。

这套流程能帮你快速定位问题是出在前端加密、传输过程还是后端解密。很多“对不上”的问题，其实是中间某个环节自己改了密钥或加了个空格。

5. 安全升级建议：从能跑到能用再到扛打

5.1 密钥别写死在源码里

前面代码为了方便演示，把密钥写死了。实际项目里至少做到：

• Vue端：在.env.development、.env.production里配置VUE_APP_AES_KEY，通过process.env.VUE_APP_AES_KEY读取；
• C#端：放到appsettings.json或环境变量里，使用IConfiguration读取；
• 定期轮换密钥：可以在数据库或配置中心维护密钥版本号，前端在启动时或登录时获取当前有效的密钥版本，这样密钥泄露后不需要紧急改代码。

还有一个现实问题：前端打包后的JS里，process.env变量会被替换成真实值，所以再怎么藏，对“会翻开发者工具的人”来说都是能看到明文密钥的。因此AES加密一定不要作为唯一防线，HTTPS仍然必须开，AES加密可以作为敏感字段的额外保护。

5.2 从CBC升级到GCM需要注意什么

如果要更高的安全性，推荐用AES-GCM模式。GCM是认证加密模式，能同时保证机密性和完整性，密文被篡改后解密时会直接抛异常，而CBC + PKCS7在密文被篡改时可能出现padding error，但有些场景下错误提示不够明显。

CryptoJS本身对GCM支持不太好，常用方案是换成crypto-js的扩展或使用Web Crypto API：

// 浏览器原生Web Crypto示例（部分代码） const encoder = new TextEncoder(); const data = encoder.encode(JSON.stringify(payload)); const key = await crypto.subtle.importKey('raw', keyBytes, { name: 'AES-GCM' }, false, ['encrypt']); const iv = crypto.getRandomValues(new Uint8Array(12)); const cipherBuffer = await crypto.subtle.encrypt({ name: 'AES-GCM', iv }, key, data);

C#端对应使用：

using (var aes = Aes.Create()) { aes.Key = keyBytes; aes.Mode = CipherMode.GCM; // .NET 5+支持AesGcm类 }

升级GCM时，IV通常用12字节随机数，解密时需要把IV和密文一起传给后端。这个改造涉及前后端协议变更，建议放到二期做，先把CBC方案跑稳。

5.3 防重放和时间戳校验

AES加密解决的是“明文泄露问题”，但加密后的密文如果被攻击者原样重放，后端依然会正常解密。为了防止重放，我一般会在加密的JSON里加一个timestamp字段：

const bizData = { ...formData, timestamp: Date.now() }

C#端解密后校验timestamp与当前时间的差值，超过比如5分钟就拒绝请求。同时可以在服务端用Redis缓存最近处理过的密文或nonce值，相同密文直接拒绝，做到真正的防重放。

但要注意：加了timestamp之后，缓存机制要处理好并发场景。同一密文在高并发下可能同时到达，Redis的分布式锁编程要谨慎，不然会误伤正常请求。

6. 最后的经验分享

我在实际联调中最大的体会是：跨语言加解密，90%的问题出在“参数不对称”，而不是“算法不会写”。密钥、IV、模式、填充、编码，每一项都要当成接口协议来对待，最好写成文档并在代码里加注释。前端封装好crypto.js之后，业务代码一行都不用改；C#端封装好AesHelper之后，控制器里就一句话的事。等这套链路跑通，再去追求GCM、动态密钥、密钥版本管理，路就顺多了。

最后分享一个小技巧：调试阶段，前端把key、iv、mode、padding、ciphertext五件套打印出来，后端解密失败时直接对照这些参数，比看报错日志高效得多。我见过太多人卡在“为什么我解不开”上，结果只是前端密钥字符串末尾多了一个空格。这个习惯养成了，前后端联调能少掉一把头发。