1. 项目概述为什么要在Apifox中引入国密算法加密在API接口测试与开发中数据安全传输是一个老生常谈却又至关重要的话题。我们经常在Apifox里配置Basic Auth、Bearer Token或者处理OAuth 2.0的授权流但这些大多解决的是身份认证Authentication和授权Authorization问题。对于传输过程中的数据本身尤其是请求体Request Body和响应体Response Body中的敏感信息比如身份证号、手机号、交易金额等如果仅依赖HTTPS我们通常默认数据是安全的。但HTTPS解决的是通道安全数据在服务端解密后在内部系统间流转或者日志记录时仍可能以明文形式暴露。这就引出了“端到端加密”End-to-End Encryption, E2EE的需求。这里的“端到端”指的是从客户端或测试工具生成数据的那一刻起到最终的服务端业务逻辑处理前数据始终处于加密状态。即使请求被中间代理、网关或日志系统捕获看到的也只是密文。这对于满足日益严格的数据安全合规要求如等保、个人信息保护法等至关重要。那么为什么是SM2和SM4SM2非对称加密和SM4对称加密是我国密码管理局认定的商用密码算法标准。在金融、政务、央企等对数据主权和安全性有极高要求的场景中使用国密算法进行数据加密和签名不仅是技术选型更是政策与合规的必然要求。Apifox作为一款强大的API协作工具其内置的“前后置脚本”功能为我们实现自定义的端到端加密逻辑提供了完美的沙箱。这个项目的核心就是利用Apifox的脚本能力在接口请求发出前自动对特定字段或整个请求体进行SM4加密并用SM2私钥签名在收到响应后自动用SM2公钥验签并用SM4密钥解密响应体将明文结果展示给测试人员。整个过程对测试人员透明他们只需关心业务参数加解密和签名验签由脚本自动完成极大地提升了涉及国密算法接口的测试效率和准确性。2. 核心思路与架构设计实现Apifox的端到端加密关键在于理解Apifox脚本的执行时机和数据流。整个设计可以概括为“前加密后解密前签名后验签”。2.1 端到端加密数据流设计一个完整的、安全的端到端加密API调用其理想的数据流如下客户端Apifox前置脚本加密使用SM4密钥对称密钥对请求体中的敏感数据或整个JSON对象进行加密生成密文。签名使用SM2私钥对“原始请求参数或加密后的密文 时间戳 随机数”等信息生成数字签名。组装将加密后的数据、签名、时间戳、随机数等组装成新的请求体或放入特定Header发送给服务端。服务端验签使用SM2公钥验证签名的合法性确保请求未被篡改且来源可信。解密使用SM4密钥解密请求体中的密文得到原始业务数据。处理执行业务逻辑。响应加密与签名同样使用SM4加密响应数据并用SM2私钥签名将密文和签名返回给客户端。客户端Apifox后置脚本验签使用SM2公钥验证响应签名的合法性。解密使用SM4密钥解密响应密文得到明文业务数据。替换将Apifox界面中显示的响应体替换为解密后的明文方便测试人员查看。在这个流程中SM4密钥是加解密的核心需要客户端和服务端安全共享。SM2的非对称特性则完美用于签名和验签确保数据的完整性和不可否认性而私钥无需在网络中传输。2.2 Apifox脚本执行位置与职责我们需要在Apifox接口的“前置脚本”和“后置脚本”两个位置编写JavaScript代码。前置脚本 (Pre-request Script)在接口请求被发送之前执行。这里是我们实现请求加密和生成签名的地方。后置脚本 (Tests Script)在接收到接口响应之后执行。这里是我们实现响应验签和响应解密的地方。2.3 密钥与参数管理策略安全实践要求我们不能将密钥硬编码在脚本里。Apifox提供了完善的环境变量和“Vault Secrets密钥库”功能。环境变量用于存储非极度敏感、因环境而异的配置。SM4_KEY: SM4对称加密密钥Base64编码或16进制字符串。SM2_PUBLIC_KEY: SM2公钥PEM格式或Base64编码。SM2_PRIVATE_KEY:谨慎SM2私钥。对于前端或测试工具私钥通常不应出现。但在我们模拟客户端完整行为的场景下需要私钥进行签名。务必将其存入Vault Secrets。ENCRYPT_ENABLED: 布尔值控制是否启用加密方便在测试环境切换。Vault Secrets密钥库这是Apifox用于存储最高机密信息的功能值在界面上会被隐藏且不会在团队协作中明文传输。SM2_PRIVATE_KEY必须放在这里。动态参数每次请求需要动态生成的参数如timestamp: 当前时间戳毫秒或秒用于防重放攻击。nonce: 随机字符串同样用于防重放。我们的脚本需要从这些地方安全地读取密钥和配置。3. 工具链准备与核心库选型在Apifox的JavaScript沙箱环境中我们不能直接使用Node.js的crypto模块或安装npm包。我们需要寻找纯JavaScriptES5/ES6实现的、支持国密算法的库并且能够在前置/后置脚本中直接通过require或pm.external引入。3.1 国密算法JavaScript库调研经过实践以下几个库是可靠的选择sm-crypto一个非常流行的国密算法JavaScript实现。它同时支持SM2和SM4且代码轻量兼容性好可以直接通过CDN引入或在Apifox中引用。优点API简洁文档清晰社区活跃。缺点SM4部分可能需要稍作调整以适应Apifox的脚本环境主要是编码问题。forge一个功能强大的JavaScript加密工具包通过插件可以支持SM3、SM4。对于SM2可能需要结合其他库。优点功能全面稳定可靠。缺点体积相对较大SM2支持不是原生。node-sm2/node-sm4Node.js原生模块无法在Apifox的浏览器沙箱环境中直接使用。结论与选型对于Apifox脚本环境sm-crypto是最佳选择。它提供了我们需要的所有核心功能且易于集成。3.2 在Apifox中引入sm-cryptoApifox脚本支持通过pm.external发送HTTP请求也支持直接执行eval需谨慎。最稳妥的方式是将sm-crypto的源码一个单独的.js文件内容直接封装在我们自己的“公共脚本”中。操作步骤访问sm-crypto的GitHub仓库或通过npm获取其压缩后的浏览器版本如sm-crypto.min.js。在Apifox项目中进入“项目设置” - “公共脚本”。点击“新建公共脚本”命名为SM_CRYPTO_LIB。将sm-crypto.min.js的整个文件内容复制粘贴到脚本编辑器中并保存。这样在任何一个接口的前置或后置脚本中我们都可以通过const smCrypto require(SM_CRYPTO_LIB);来引入这个库。这是Apifox脚本模块化的一种有效方式。3.3 辅助函数准备在编写具体的加解密脚本前我们先准备一些通用的辅助函数放在另一个公共脚本里比如叫E2E_HELPER。// 公共脚本E2E_HELPER const smCrypto require(SM_CRYPTO_LIB); // 引入我们封装的sm-crypto class E2EHelper { constructor() { // 从环境变量和Vault读取配置 this.sm4Key pm.environment.get(SM4_KEY); // 假设是16进制字符串32字节256位 this.sm2PublicKey pm.environment.get(SM2_PUBLIC_KEY); // 公钥 // 私钥从Vault Secrets读取这是一个更安全的模拟 // 注意pm.vault.get() 可能需要根据Apifox版本调整这里用环境变量模拟Vault this.sm2PrivateKey pm.environment.get(SM2_PRIVATE_KEY_VAULT); // 实际应从Vault获取 this.encryptEnabled pm.environment.get(ENCRYPT_ENABLED) true; } // 生成随机字符串用于nonce generateNonce(length 16) { const chars ABCDEFGHJKMNPQRSTWXYZabcdefhijkmnprstwxyz2345678; let result ; for (let i 0; i length; i) { result chars.charAt(Math.floor(Math.random() * chars.length)); } return result; } // 获取当前时间戳秒 getTimestamp() { return Math.floor(Date.now() / 1000).toString(); } // SM4 ECB模式加密 (输入: 明文字符串, 输出: 16进制密文字符串) sm4Encrypt(plainText) { if (!this.sm4Key) { throw new Error(SM4_KEY is not configured.); } // sm-crypto的sm4.encrypt默认使用ECB模式PKCS#7填充 // 注意key需要是16进制字符串且长度为32256位 const encryptedData smCrypto.sm4.encrypt(plainText, this.sm4Key); return encryptedData; } // SM4 ECB模式解密 (输入: 16进制密文字符串, 输出: 明文字符串) sm4Decrypt(cipherTextHex) { if (!this.sm4Key) { throw new Error(SM4_KEY is not configured.); } const decryptedData smCrypto.sm4.decrypt(cipherTextHex, this.sm4Key); return decryptedData; } // SM2 签名 (输入: 待签名字符串, 输出: 16进制签名字符串) sm2Sign(msg) { if (!this.sm2PrivateKey) { throw new Error(SM2_PRIVATE_KEY is not configured.); } // sm-crypto的sm2.doSignature默认输出为16进制字符串 // 使用默认的SM3摘要算法 const signResult smCrypto.sm2.doSignature(msg, this.sm2PrivateKey); return signResult; } // SM2 验签 (输入: 原始消息字符串, 16进制签名字符串, 输出: 布尔值) sm2Verify(msg, signHex) { if (!this.sm2PublicKey) { throw new Error(SM2_PUBLIC_KEY is not configured.); } const verifyResult smCrypto.sm2.doVerifySignature(msg, signHex, this.sm2PublicKey); return verifyResult; } // 组装加密请求体 buildEncryptedRequestBody(originalData) { const timestamp this.getTimestamp(); const nonce this.generateNonce(); // 1. 序列化原始数据 const dataString typeof originalData string ? originalData : JSON.stringify(originalData); // 2. SM4加密数据 const encryptedData this.sm4Encrypt(dataString); // 3. 构造待签名字符串通常包含加密数据、时间戳、随机数 // 格式可根据与后端约定调整例如encryptedData|timestamp|nonce const signString ${encryptedData}|${timestamp}|${nonce}; // 4. SM2签名 const signature this.sm2Sign(signString); // 5. 组装最终请求体 const finalBody { encryptData: encryptedData, // 加密后的业务数据 timestamp: timestamp, nonce: nonce, sign: signature, // 可以添加其他协议字段如版本号 version: 1.0 }; return finalBody; } // 解析并验证响应 parseAndVerifyResponse(encryptedResponse) { // 假设响应体结构与请求体类似{ encryptData, timestamp, nonce, sign } const { encryptData, timestamp, nonce, sign } encryptedResponse; // 1. 验证签名 const signString ${encryptData}|${timestamp}|${nonce}; const isSignValid this.sm2Verify(signString, sign); if (!isSignValid) { throw new Error(Response signature verification failed! The data may be tampered with.); } // 2. 解密数据 const decryptedDataString this.sm4Decrypt(encryptData); // 3. 尝试解析为JSON如果不是JSON则返回字符串 try { return JSON.parse(decryptedDataString); } catch (e) { return decryptedDataString; } } } // 导出单例或类供接口脚本使用 if (typeof module ! undefined) { module.exports new E2EHelper(); }注意以上代码是一个高度简化的示例。在实际生产级应用中你需要和后端开发人员严格约定加密模式如SM4的ECB、CBC模式以及初始向量IV。填充方式如PKCS#7。数据编码Hex还是Base64。待签名字符串的拼接规则和顺序。错误处理机制和状态码。4. 前置脚本实现请求的自动加密与签名现在我们可以在具体接口的“前置脚本”中调用上面准备好的工具类实现请求的自动处理。假设我们有一个用户注册接口POST /api/v1/user/register其原始请求体明文如下{ phone: 13800138000, idCard: 110101199001011234, name: 张三 }我们的目标是在请求发出前将整个phone、idCard字段加密或者根据业务规则加密整个请求体。4.1 完整的前置脚本示例// 1. 引入辅助工具类 const helper require(E2E_HELPER); // 2. 检查是否启用加密 if (!helper.encryptEnabled) { console.log(E2E encryption is disabled. Sending plain request.); return; // 如果不启用直接跳过 } // 3. 获取当前的请求对象和原始数据 const request pm.request; const requestBody request.body; // 检查请求体格式我们只处理JSON if (requestBody.mode raw requestBody.options?.raw?.language json) { try { const rawData requestBody.raw; const jsonData JSON.parse(rawData); // 4. 【策略选择】选择加密范围 // 策略A加密整个请求体 // const finalRequestBody helper.buildEncryptedRequestBody(jsonData); // 策略B只加密特定敏感字段其他字段保持不变更常见 const sensitiveFields [phone, idCard]; // 定义需要加密的字段名 const dataToEncrypt {}; const dataRemain {}; for (const key in jsonData) { if (sensitiveFields.includes(key)) { dataToEncrypt[key] jsonData[key]; } else { dataRemain[key] jsonData[key]; } } // 将敏感字段对象加密成一个字符串放入特定字段如 encryptedData const encryptedSensitiveData helper.sm4Encrypt(JSON.stringify(dataToEncrypt)); // 5. 构造待签名的数据包 const timestamp helper.getTimestamp(); const nonce helper.generateNonce(); // 签名数据可以包含加密后的数据、时间戳、随机数和剩余的非敏感数据确保整体完整性 const signDataObject { encrypted: encryptedSensitiveData, timestamp: timestamp, nonce: nonce, remain: dataRemain // 将非敏感数据也纳入签名计算防止被篡改 }; const signString JSON.stringify(signDataObject); // 将对象序列化后签名 const signature helper.sm2Sign(signString); // 6. 组装最终请求体 const finalBody { ...dataRemain, // 非敏感字段原样传递 encryptedData: encryptedSensitiveData, // 加密的敏感字段集合 timestamp: timestamp, nonce: nonce, sign: signature }; // 7. 更新Apifox的请求体 requestBody.update({ mode: raw, raw: JSON.stringify(finalBody, null, 2), options: { raw: { language: json } } }); // 8. 【可选】可以添加一些自定义Header告知服务端这是加密请求 request.headers.upsert({ key: X-Encrypt-Type, value: SM2-SM4-E2E }); console.log(Request encrypted and signed successfully.); console.log(Final request body:, JSON.stringify(finalBody, null, 2)); } catch (error) { console.error(Error during request encryption:, error.message); // 可以选择抛出错误阻止请求发送 // throw error; } } else { console.warn(Request body is not in JSON format. E2E encryption skipped.); }4.2 关键点与注意事项加密粒度是加密整个请求体还是仅加密部分字段这需要与后端架构师共同决定。加密部分字段更灵活但签名计算需要涵盖所有字段包括未加密的以确保整体请求的完整性。错误处理加密或签名过程可能失败如密钥格式错误。脚本中必须有健壮的try-catch并决定失败时是抛出错误中止请求还是降级为明文发送需有明确标识。在生产测试中通常应中止请求。日志输出使用console.log输出关键步骤信息对于调试至关重要。但注意不要打印出密钥等敏感信息。Header标识添加如X-Encrypt-Type的自定义Header是一个好习惯方便服务端网关或中间件快速识别并路由到相应的解密处理器。5. 后置脚本实现响应的自动验签与解密服务端返回的响应我们假设其结构为{ code: 200, message: success, data: { encryptedData: a1b2c3d4...SM4加密后的业务数据, timestamp: 1712345678, nonce: AbCdEfGh12345678, sign: 5f6g7h8i...SM2签名 } }或者响应体整个就是一个加密对象。后置脚本的任务是自动验签、解密并将pm.response.json()替换为解密后的明文数据。5.1 完整的后置脚本示例// 1. 引入辅助工具类 const helper require(E2E_HELPER); // 2. 检查是否启用加密及响应状态 if (!helper.encryptEnabled) { console.log(E2E encryption is disabled. Displaying plain response.); return; } // 仅处理成功的响应如2xx状态码错误响应可能本身就是明文 if (pm.response.code 200 pm.response.code 300) { try { const responseJson pm.response.json(); // 3. 判断响应结构 // 情况A整个响应体就是加密协议包 let encryptedPayload null; let isNested false; if (responseJson.encryptedData responseJson.sign) { // 结构{ encryptedData, timestamp, nonce, sign, ... } encryptedPayload responseJson; } else if (responseJson.data responseJson.data.encryptedData responseJson.data.sign) { // 结构{ code, message, data: { encryptedData, timestamp, nonce, sign } } encryptedPayload responseJson.data; isNested true; } else { console.log(Response is not in encrypted format. Displaying as is.); return; } // 4. 调用工具类进行验签和解密 const decryptedBusinessData helper.parseAndVerifyResponse(encryptedPayload); console.log(Response decrypted and verified successfully.); console.log(Decrypted business data:, JSON.stringify(decryptedBusinessData, null, 2)); // 5. 替换Apifox的响应体这是最关键的一步 // 我们需要修改pm.response的内部表示使其后续的pm.response.json()调用返回解密后的数据。 // Apifox提供了 pm.response.json() 的替换方法。 if (isNested) { // 如果加密数据在 data 字段内则用解密后的业务数据替换整个 data 字段 responseJson.data decryptedBusinessData; // 同时可以清理掉协议字段避免混淆 // delete responseJson.data.encryptedData; // 解密后这些字段已无意义可删除 // delete responseJson.data.sign; // delete responseJson.data.timestamp; // delete responseJson.data.nonce; } else { // 如果整个响应体就是加密包则直接用解密后的业务对象替换整个响应对象 // 注意这要求解密后的数据本身就是一个完整的响应结构如 { code, message, data } // 如果解密后只是业务数据可能需要重新包装 // 这里假设解密后的数据就是最终的响应体 Object.keys(responseJson).forEach(key delete responseJson[key]); // 清空原对象 Object.assign(responseJson, decryptedBusinessData); // 将解密数据合并进去 } // 重要更新响应文本这样在“Pretty”、“Raw”等视图下看到的就是解密后的内容 // 注意直接修改 pm.response.json() 返回的对象可能不会自动更新UI。 // 更可靠的方法是使用 pm.response.to.have.json 或直接替换 pm.response.text如果知道结构。 // 一种实用的方法是将解密后的数据设置到一个环境变量或全局变量供后续断言使用。 // 但为了在界面直接显示我们可以尝试覆盖 pm.response.text。 try { pm.response.text JSON.stringify(responseJson, null, 2); } catch (e) { console.warn(Failed to update response text directly:, e.message); } // 将解密后的数据存入一个临时变量方便在“Tests”标签页的其他断言中使用 pm.environment.set(DECRYPTED_RESPONSE, JSON.stringify(decryptedBusinessData)); } catch (error) { console.error(Error during response decryption or verification:, error.message); // 验签失败或解密失败可以标记测试失败 pm.test(E2E Decryption Failed - ${error.message}, () { pm.expect.fail(Response security check failed: ${error.message}); }); } } else { console.log(Received error status code: ${pm.response.code}. Skipping E2E decryption.); }5.2 关键点与注意事项响应结构判断服务端返回的加密响应结构必须提前约定好。脚本需要能灵活判断是“整体加密”还是“嵌套加密”即data字段内是加密包。这部分逻辑需要根据实际接口规范调整。响应体替换的局限性Apifox的脚本环境对pm.response对象的修改有一定限制。直接修改pm.response.json()返回的对象有时不会实时反映在UI的“响应”预览面板上。上述脚本中通过覆写pm.response.text是一种尝试可能在某些版本有效。最可靠的方法是将解密后的数据存入环境变量如DECRYPTED_RESPONSE。在“Tests”标签页的断言中从这个环境变量读取数据进行校验。接受一个事实在“Pretty”视图下看到的可能仍是原始密文但你的断言脚本可以基于解密后的数据进行验证。这对于自动化测试来说已经足够。错误处理验签失败是一个严重的安全事件必须导致测试用例失败。使用pm.test和pm.expect.fail来明确标记。性能考虑SM2签名验签和SM4加解密是计算密集型操作。如果响应体很大解密可能会稍微增加脚本执行时间。对于性能测试场景需要评估其影响。6. 环境配置与密钥管理实战理论再好离不开实战配置。下面一步步讲解如何在Apifox中安全地配置这个端到端加密流程。6.1 创建环境变量与Vault Secret创建环境在Apifox左侧栏进入“环境管理”。创建一个新环境命名为“国密加密测试环境”。添加环境变量SM4_KEY: 填入一个32字节的16进制字符串64个字符例如0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef。请务必使用与后端服务协商一致的密钥。SM2_PUBLIC_KEY: 填入SM2公钥PEM格式或Base64编码。可以从后端开发或运维人员处获取。ENCRYPT_ENABLED: 设置为true。添加Vault Secret密钥库在“项目设置”或“团队设置”中找到“Vault Secrets”不同版本位置可能不同。添加一个新的Secret名称设为SM2_PRIVATE_KEY值填入你的SM2私钥。重要在环境变量中我们不直接引用这个Vault Secret的值。在脚本中我们通过pm.vault.get(SM2_PRIVATE_KEY)来获取。但请注意Apifox脚本API可能随版本变化。一种更通用的方法是在环境变量中存储一个指向Vault的标识符或者如果团队协作安全要求允许可以将私钥的测试环境专用版本直接存入环境变量仅用于测试与生产私钥不同。绝对不要将生产私钥硬编码或明文存储在非Vault的地方。6.2 在脚本中读取Vault SecretApifox的脚本API文档是查找正确方法的地方。通常读取Vault的语法类似于// 方式一可能通过 pm.vault 对象 (请查阅最新Apifox文档) const privateKeyFromVault pm.vault.get(SM2_PRIVATE_KEY); // 方式二可能通过环境变量前缀如 {{$vault.SM2_PRIVATE_KEY}} 在脚本中无法直接解析 // 需要先在“前置脚本”或“后置脚本”的顶部通过pm.environment.set一个临时变量。 // 但这通常是在请求URL/Header/Body中使用的语法在脚本中可能需要不同的方法。 // 方式三务实方案如果只是团队内部测试且环境安全可控 // 可以将测试专用的SM2私钥直接以环境变量形式存储命名为 SM2_PRIVATE_KEY_FOR_TEST。 // 在辅助类构造函数中读取 this.sm2PrivateKey pm.environment.get(SM2_PRIVATE_KEY_FOR_TEST);安全警告选择哪种方式取决于你的安全策略。对于涉及真实敏感数据的测试务必使用Vault并遵循最小权限原则。6.3 将脚本应用到接口或文件夹单个接口在接口的“前置脚本”和“后置脚本”标签页中分别粘贴第4章和第5章的脚本代码。批量应用推荐如果多个接口都需要相同的加密逻辑可以将其封装成“公共脚本”然后在每个接口的脚本中简单地调用公共函数。创建公共脚本E2E_ENCRYPTION_HANDLER。将前置和后置处理逻辑写成两个函数例如handlePreRequest()和handlePostResponse()。在具体接口的脚本中只需写// 前置脚本 require(E2E_ENCRYPTION_HANDLER).handlePreRequest();// 后置脚本 require(E2E_ENCRYPTION_HANDLER).handlePostResponse();文件夹级脚本Apifox支持为整个文件夹设置前置/后置脚本该文件夹下的所有接口都会自动运行这些脚本。这是管理具有相同安全要求的接口组最有效率的方式。7. 调试技巧与常见问题排查即使按照步骤操作你也可能会遇到各种问题。以下是一些常见的坑和排查思路。7.1 常见问题速查表问题现象可能原因排查步骤前置脚本报错smCrypto is not defined公共脚本SM_CRYPTO_LIB未正确创建或引入。1. 检查SM_CRYPTO_LIB公共脚本是否存在且内容完整。2. 检查前置脚本中require的脚本名称是否完全一致区分大小写。3. 在脚本开头加console.log(typeof require)检查require函数是否可用。加密失败Invalid key lengthSM4密钥格式或长度错误。1. 确认密钥是32字节256位的16进制字符串64个字符。2. 检查环境变量SM4_KEY的值前后是否有空格。3. 使用console.log(Key:, pm.environment.get(SM4_KEY))打印出来确认。签名失败Invalid private keySM2私钥格式错误。1. 确认私钥是有效的PEM格式或Base64编码的原始私钥。2.sm-crypto的SM2私钥通常支持“04”开头的公钥和不带“04”的原始私钥十六进制串。查阅其文档确认格式。3. 尝试使用一个已知可用的密钥对进行单元测试。服务端返回“签名无效”客户端和服务端签名/验签规则不一致。1.这是最常见的问题。核对“待签名字符串”的拼接规则字段顺序、分隔符、是否包含所有必要字段如encryptedData,timestamp,nonce。2. 确认双方使用的SM2签名摘要算法是否一致默认都是SM3。3. 在前置脚本中打印出signString与后端日志对比看是否完全一致。服务端无法解密加密模式、填充或编码不一致。1. 确认双方SM4使用的模式如ECB、CBC。sm-crypto默认是ECB。2. 确认填充方式如PKCS#7。3. 确认输入输出是字符串还是16进制。sm-crypto的sm4.encrypt(明文, key)默认输出16进制字符串。检查后端期望的是Hex还是Base64。4. 如果使用CBC模式初始向量IV必须一致。后置脚本解密后响应显示乱码解密成功但数据格式非JSON或替换响应体方式不当。1. 在helper.parseAndVerifyResponse解密后用console.log打印decryptedBusinessData的类型和内容。2. 如果解密后是字符串但不是JSONApifox的JSON预览会报错。需要根据实际情况处理如如果解密后是XML则无需强制JSON解析。3. 如果只是想在断言中使用解密数据可以忽略UI显示专注于pm.environment.set(DECRYPTED_RESPONSE, ...)和后续的pm.test断言。脚本执行超时处理的数据量过大或脚本逻辑有死循环。1. SM4加密大文件或超长字符串会耗时。考虑是否真的需要加密整个巨大的JSON。2. 优化脚本逻辑避免在循环中进行复杂操作。3. 检查Apifox设置的脚本超时时间如果有相关设置。7.2 调试心得与技巧善用console.log这是Apifox脚本调试最重要的工具。在前置脚本中打印出原始请求体、加密后的密文、待签名字符串、生成的签名。在后置脚本中打印出收到的响应体、验签结果、解密后的明文。将这些信息与服务端日志对比几乎所有问题都能定位。先本地验证算法在集成到Apifox之前先用Node.js或浏览器写一个简单的本地测试页面使用相同的sm-crypto库和密钥模拟加密、解密、签名、验签全过程。确保你的JavaScript代码逻辑本身是正确的。与后端对齐每一个细节端到端加密的成功99%依赖于客户端与服务端的协议一致性。务必共同确认并文档化以下内容加密算法SM4模式ECB/CBC填充PKCS#7密钥长度256位密钥格式Hex/Base64。签名算法SM2withSM3。协议字段请求/响应体中必须包含哪些字段如encryptedData,timestamp,nonce,sign,version。待签名字符串格式精确到字段名、顺序、分隔符。例如encryptedData{}timestamp{}nonce{}还是{encryptedData}|{timestamp}|{nonce}。时间戳与防重放时间戳的单位秒/毫秒允许的时钟漂移范围如±5分钟。分步启用不要一开始就在所有接口上启用。先在一个简单的、非核心的接口如“获取服务器时间”上测试整套流程。从“不加密” - “只加密” - “加密且签名”逐步验证。利用Apifox的“控制台”在Apifox的设置中打开“显示脚本执行日志”或类似选项这样你可以在请求结束后在一个单独的面板中看到所有console.log的输出非常方便。8. 进阶优化与扩展思路当基础功能跑通后可以考虑以下优化让这套加密机制更健壮、更易用。动态密钥协商上述方案使用静态的SM4密钥。更安全的做法是仿照HTTPS每次会话由客户端生成一个随机的“会话密钥”用SM2公钥加密后传给服务端后续通信都用这个会话密钥进行SM4加密。这可以前置于登录或握手接口实现。算法套件可配置化将加密算法、模式、填充方式等也做成环境变量。这样同一套脚本可以支持不同的加密套件例如未来可能切换到SM4-GCM模式。性能优化缓存密钥对象sm-crypto的sm4.encrypt每次调用都可能内部初始化密钥。如果一次测试运行中要调用多次加密可以考虑在辅助类中缓存初始化后的加密/解密上下文对象提升性能。集成到Apifox CLI/CI/CDApifox CLI支持运行集合Collection和场景Scenario。你需要确保在命令行运行时环境变量和Vault Secret也能被正确加载。这通常需要通过环境变量文件或CI/CD系统的Secret管理功能来实现。生成代码片段你可以将加密/解密/签名/验签的核心函数封装成Apifox的“代码生成模板”的一部分。这样开发人员在生成前端或后端调用代码时可以直接得到包含国密算法处理的代码片段保证客户端和服务端实现的一致性。实现Apifox的国密算法端到端加密初看步骤不少但一旦打通就会成为团队测试国密相关API的标准化、自动化利器。它把复杂的密码学操作隐藏在脚本之后让测试和开发人员能像测试普通接口一样测试加密接口真正做到了关注点分离。