1. 项目概述：为什么我们需要一套完整的国密SM4前后端加密方案？

最近在做一个涉及敏感数据传输的项目，甲方明确要求使用国密算法。一开始我寻思着，不就是个加密解密嘛，找个库调一下API不就行了？结果在实际对接中踩了一堆坑：前端加密了后端解不开、不同语言库的默认模式对不上、密钥和IV的编码格式五花八门……折腾下来，深刻体会到，一个“能用”的加密功能和一套“可靠”的加密体系，中间差了十万八千里。尤其是在国密算法生态不如AES那么普及的当下，自己从头到尾捋清楚并实现一套前后端一致的SM4加解密方案，成了刚需。

SM4作为我国官方认定的商用密码标准，其安全性和效率已经过充分验证，在金融、政务、物联网等领域应用越来越广。它和AES一样，属于分组对称加密算法，密钥和分组长度都是128位。但和直接调用CryptoJS.AES.encrypt就能跑通不同，SM4的跨语言、跨平台实现，更需要我们关注细节上的一致性。这套完整代码方案，就是为了解决这个痛点：提供从前端JavaScript到后端Java/Python/Go等语言的、开箱即用、经过互操作性验证的SM4 CBC模式加解密实现，让你能真正安全高效地在实际项目中落地国密加密。

2. 核心设计思路：构建高互操作性的加密通信层

当我们要设计一个前后端通用的加密方案时，核心目标不是“实现算法”，而是“建立一套双方都能无歧义理解的通信规则”。算法本身是标准的，但如何使用它，却充满了“陷阱”。

2.1 为什么选择CBC模式而非ECB？

首先面临的是加密模式的选择。SM4支持ECB和CBC等模式。ECB（电子密码本）模式最简单，相同的明文块会产生相同的密文块，这在加密大量重复数据或图片时，会暴露模式信息，安全性不足。而CBC（密码分组链接）模式引入了初始化向量（IV），使得每个块的加密都依赖于前一个块，相同的明文块加密后也会得到不同的密文块，安全性更高。因此，在绝大多数需要保密性的场景下，CBC是默认且推荐的选择。我们的方案也基于CBC模式构建。

2.2 密钥与IV的生成与管理策略

密钥是加密的根基。对于SM4，我们需要一个128位（16字节）的密钥。在实际项目中，绝对不应该使用硬编码在代码里的固定密钥。常见的做法是：

1. 由后端生成并安全传输：在会话建立初期（如登录时），后端生成一个随机的密钥和IV，通过非对称加密（如SM2或RSA）安全地传给前端。后续通信均使用该对称密钥。
2. 基于口令派生：如果加密是为了本地存储（如加密本地缓存的数据），可以使用PBKDF2、Scrypt等算法，从一个用户口令派生出一个固定长度的密钥。这能有效抵御暴力破解。

IV（初始化向量）在CBC模式中至关重要，它不需要保密，但必须不可预测，且通常需要随密文一起传输。一个重要的原则是：同一个密钥下，绝对不要重复使用相同的IV。否则会严重削弱安全性。我们的实现中，每次加密都会生成一个随机的16字节IV，并将其拼接到密文头部，解密时再从中提取。

2.3 数据填充方案的统一

SM4是分组密码，一次处理128位（16字节）的数据。但我们的明文长度通常是任意的。因此，需要对最后一个不满足16字节的块进行填充。PKCS#7/PKCS#5填充是最通用和推荐的标准。它的规则是：缺N个字节，就填充N个值为N的字节。例如，一个15字节的数据，缺1字节，就填充1个0x01；一个16字节的数据，则需要额外填充一个完整的16字节块，每个字节都是0x10。这样在解密时，可以通过最后一个字节的值，明确地移除填充。前后端必须使用完全相同的填充方案，否则解密后会得到一堆乱码。

2.4 编码与传输格式的约定

这是前后端联调中最容易出错的地方。加密操作处理的是字节数组，但我们在网络中传输的是文本（如JSON）。因此，需要将字节数组编码为可打印的字符串。Base64编码是最佳选择，它能将二进制数据安全地转换为ASCII字符，且编码后体积只增加约33%。我们将统一约定：密钥、IV、最终的密文，在需要字符串形式表示时，均使用Base64编码。在内存或某些API交互中，也可能使用十六进制（Hex）字符串，但在我们的核心方案中，Base64是默认的“通用语言”。

3. 前端JavaScript实现详解

前端我们使用一个较为成熟的库sm-crypto，它纯JavaScript实现，不依赖特定环境，同时支持SM2和SM4。

3.1 环境准备与库引入

首先，在你的前端项目中安装sm-crypto。如果你使用npm管理项目，执行以下命令：

npm install sm-crypto --save

或者，你也可以直接在HTML中通过CDN引入：

<script src="https://unpkg.com/sm-crypto@latest/dist/sm-crypto.min.js"></script>

引入后，全局变量smCrypto或模块导入的smCrypto对象就包含了我们需要的所有方法。

3.2 核心加密函数实现

我们封装一个名为sm4Encrypt的函数，它接受明文、Base64编码的密钥和IV（如果未提供IV则随机生成），返回Base64编码的密文（IV已拼接在密文头部）。

import { sm4 } from 'sm-crypto'; /** * SM4 CBC模式加密 * @param {string} plainText - 待加密的明文 * @param {string} keyBase64 - Base64编码的16字节密钥 * @param {string} [ivBase64] - Base64编码的16字节IV，若不传则随机生成 * @returns {string} Base64编码的密文（格式：IV + 密文） */ function sm4Encrypt(plainText, keyBase64, ivBase64) { // 1. 将Base64编码的密钥和IV转换为WordArray格式（库内部所需格式） const key = sm4.utils.base64ToArray(keyBase64); let iv; if (ivBase64) { iv = sm4.utils.base64ToArray(ivBase64); } else { // 随机生成16字节IV iv = sm4.utils.generateRandomArray(16); } // 2. 执行加密，使用CBC模式和PKCS#7填充 // sm4.encrypt参数：明文，密钥，配置对象 const encryptedArray = sm4.encrypt(plainText, key, { mode: 'cbc', // 加密模式 iv: iv, // 初始化向量 padding: 'pkcs#7', // 填充方式 output: 'array' // 输出格式为数组 }); // 3. 将IV和密文数组合并，然后转换为Base64字符串 // 注意：IV本身也是字节数组，需要和密文拼接在一起传输 const ivAndCipherArray = iv.concat(encryptedArray); const ivAndCipherBase64 = sm4.utils.arrayToBase64(ivAndCipherArray); return ivAndCipherBase64; }

关键点解析：

• sm4.utils.base64ToArray和sm4.utils.arrayToBase64是库提供的工具函数，用于在Base64字符串和字节数组之间转换。这是保证数据格式正确的关键。
• sm4.utils.generateRandomArray(16)用于生成密码学安全的随机IV。在浏览器环境中，它底层依赖window.crypto.getRandomValues。
• 配置对象中的output: 'array'指定输出为字节数组，方便我们进行后续的拼接操作。
• 最终返回的字符串，前16个字节（解码后）是IV，后面才是真正的密文。这是一种常见的传输约定。

3.3 核心解密函数实现

相应地，我们实现解密函数sm4Decrypt。它需要从拼接的字符串中分离出IV和密文。

/** * SM4 CBC模式解密 * @param {string} ivAndCipherBase64 - Base64编码的字符串（IV + 密文） * @param {string} keyBase64 - Base64编码的16字节密钥 * @returns {string} 解密后的明文 */ function sm4Decrypt(ivAndCipherBase64, keyBase64) { // 1. 将Base64字符串解码为字节数组 const ivAndCipherArray = sm4.utils.base64ToArray(ivAndCipherBase64); // 2. 分离IV和密文：前16字节是IV，之后是密文 const iv = ivAndCipherArray.slice(0, 16); const cipherArray = ivAndCipherArray.slice(16); // 3. 将Base64密钥解码 const key = sm4.utils.base64ToArray(keyBase64); // 4. 执行解密 const decryptedText = sm4.decrypt(cipherArray, key, { mode: 'cbc', iv: iv, padding: 'pkcs#7', output: 'string' // 输出为字符串 }); return decryptedText; }

关键点解析：

• slice(0, 16)和slice(16)是JavaScript数组的标准方法，用于精确分割IV和密文。这里对“16字节”的假设必须与加密端严格一致。
• 解密配置中的output: 'string'告诉库，我们希望直接得到明文字符串。库内部会自动处理PKCS#7填充的移除。

3.4 前端使用示例与注意事项

// 示例：假设后端下发了密钥（实际中应由后端通过安全信道传输） const serverKeyBase64 = '2B7E151628AED2A6ABF7158809CF4F3C'; // 这是一个示例密钥的Hex，实际应为Base64 // 注意：上面的Hex字符串需要先转成Base64。一个在线工具转换后是 `K34VFiiu0qar9xWIkJz08w==` const actualKeyBase64 = 'K34VFiiu0qar9xWIkJz08w=='; const plainText = '这是一段需要加密的敏感数据，比如身份证号或交易金额。'; // 加密 const encryptedData = sm4Encrypt(plainText, actualKeyBase64); console.log('加密结果(Base64):', encryptedData); // 输出类似：`R0NDQyMDAwMDAwMDAwMDAwMA==...` 很长一串，前面部分是IV。 // 解密（通常用于解密后端返回的密文，或本地存储数据的读取） const decryptedText = sm4Decrypt(encryptedData, actualKeyBase64); console.log('解密结果:', decryptedText); // 应与原始明文一致

注意事项：

1. 密钥安全：前端的JavaScript代码是公开的，绝对不能将长期有效的敏感密钥硬编码其中。密钥应由后端在每次会话或每次操作时动态生成并提供，或通过非对称加密方式安全交换。
2. 错误处理：上述示例未包含错误处理。在实际应用中，加解密过程可能因数据格式错误、密钥错误等失败，务必使用try...catch包裹。
3. 编码一致性：确保待加密的明文字符串的编码（通常是UTF-8）与后端预期一致。sm-crypto库内部处理的是UTF-8字符串。

4. 后端Java实现详解

后端我们使用Bouncy Castle这个强大的密码学提供者，它提供了对国密算法的完整支持。

4.1 添加项目依赖

对于Maven项目，在pom.xml中添加依赖：

<dependency> <groupId>org.bouncycastle</groupId> <artifactId>bcprov-jdk15to18</artifactId> <version>1.76</version> <!-- 请使用最新版本 --> </dependency>

对于Gradle项目：

implementation 'org.bouncycastle:bcprov-jdk15to18:1.76'

4.2 核心工具类封装

我们创建一个Sm4Util工具类，集中处理加解密逻辑。

import org.bouncycastle.jce.provider.BouncyCastleProvider; import javax.crypto.Cipher; import javax.crypto.spec.IvParameterSpec; import javax.crypto.spec.SecretKeySpec; import java.security.Security; import java.util.Base64; public class Sm4Util { static { // 静态代码块，注册Bouncy Castle提供者，只需执行一次 Security.addProvider(new BouncyCastleProvider()); } private static final String ALGORITHM_NAME = "SM4"; private static final String TRANSFORMATION = "SM4/CBC/PKCS7Padding"; // 指定算法/模式/填充 private static final int KEY_SIZE = 128; // 密钥长度，单位bit /** * 生成随机的SM4密钥（16字节） * @return Base64编码的密钥字符串 */ public static String generateKey() throws Exception { byte[] keyBytes = new byte[KEY_SIZE / 8]; // 128 bit = 16 bytes SecureRandom secureRandom = new SecureRandom(); secureRandom.nextBytes(keyBytes); return Base64.getEncoder().encodeToString(keyBytes); } /** * SM4 CBC模式加密 * @param plainText 明文 * @param keyBase64 Base64编码的密钥 * @return Base64编码的字符串，格式为：IV + 密文 */ public static String encrypt(String plainText, String keyBase64) throws Exception { // 1. 解码密钥 byte[] keyBytes = Base64.getDecoder().decode(keyBase64); SecretKeySpec secretKeySpec = new SecretKeySpec(keyBytes, ALGORITHM_NAME); // 2. 生成随机IV byte[] ivBytes = new byte[16]; // SM4分组大小是16字节 SecureRandom secureRandom = new SecureRandom(); secureRandom.nextBytes(ivBytes); IvParameterSpec ivParameterSpec = new IvParameterSpec(ivBytes); // 3. 初始化Cipher为加密模式 Cipher cipher = Cipher.getInstance(TRANSFORMATION, "BC"); // 指定使用BC提供者 cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec, ivParameterSpec); // 4. 执行加密 byte[] cipherBytes = cipher.doFinal(plainText.getBytes(StandardCharsets.UTF_8)); // 5. 合并IV和密文，然后Base64编码 byte[] ivAndCipherBytes = new byte[ivBytes.length + cipherBytes.length]; System.arraycopy(ivBytes, 0, ivAndCipherBytes, 0, ivBytes.length); System.arraycopy(cipherBytes, 0, ivAndCipherBytes, ivBytes.length, cipherBytes.length); return Base64.getEncoder().encodeToString(ivAndCipherBytes); } /** * SM4 CBC模式解密 * @param ivAndCipherTextBase64 Base64编码的字符串（IV + 密文） * @param keyBase64 Base64编码的密钥 * @return 解密后的明文 */ public static String decrypt(String ivAndCipherTextBase64, String keyBase64) throws Exception { // 1. 解码Base64字符串，得到IV+密文的字节数组 byte[] ivAndCipherBytes = Base64.getDecoder().decode(ivAndCipherTextBase64); // 2. 分离IV和密文 byte[] ivBytes = new byte[16]; byte[] cipherBytes = new byte[ivAndCipherBytes.length - 16]; System.arraycopy(ivAndCipherBytes, 0, ivBytes, 0, 16); System.arraycopy(ivAndCipherBytes, 16, cipherBytes, 0, cipherBytes.length); // 3. 解码密钥 byte[] keyBytes = Base64.getDecoder().decode(keyBase64); SecretKeySpec secretKeySpec = new SecretKeySpec(keyBytes, ALGORITHM_NAME); IvParameterSpec ivParameterSpec = new IvParameterSpec(ivBytes); // 4. 初始化Cipher为解密模式 Cipher cipher = Cipher.getInstance(TRANSFORMATION, "BC"); cipher.init(Cipher.DECRYPT_MODE, secretKeySpec, ivParameterSpec); // 5. 执行解密 byte[] plainBytes = cipher.doFinal(cipherBytes); return new String(plainBytes, StandardCharsets.UTF_8); } }

关键点解析：

• TRANSFORMATION = "SM4/CBC/PKCS7Padding"：这是Bouncy Castle中SM4算法的标准名称。注意是“PKCS7Padding”，不是“PKCS5Padding”。在分组密码中，PKCS#5和PKCS#7在填充上本质相同，但Java标准库通常用PKCS5，而BC对国密支持PKCS7，这里必须写对。
• Cipher.getInstance(TRANSFORMATION, "BC")：第二个参数“BC”明确指定使用Bouncy Castle提供者，避免使用其他可能不支持SM4的提供者。
• System.arraycopy：这是Java中高效的数组拷贝方法，用于合并和分离IV与密文。
• StandardCharsets.UTF_8：明确指定编解码字符集为UTF-8，这是与前端保持一致的关键。

4.3 后端使用示例

public class Main { public static void main(String[] args) { try { // 1. 生成密钥（实际应由系统安全存储或动态生成） String keyBase64 = Sm4Util.generateKey(); System.out.println("生成的密钥(Base64): " + keyBase64); String plainText = "Hello, 国密SM4!"; // 2. 加密 String encrypted = Sm4Util.encrypt(plainText, keyBase64); System.out.println("加密结果: " + encrypted); // 3. 解密 String decrypted = Sm4Util.decrypt(encrypted, keyBase64); System.out.println("解密结果: " + decrypted); System.out.println("加解密结果是否一致: " + plainText.equals(decrypted)); } catch (Exception e) { e.printStackTrace(); } } }

5. 后端Python实现详解

Python生态中，gmssl库是国密算法的热门选择。它基于C实现，效率较高。

5.1 安装gmssl库

pip install gmssl

5.2 核心加解密函数实现

import base64 import os from gmssl import sm4 class SM4Util: @staticmethod def generate_key(): """生成随机的16字节密钥，返回Base64字符串""" key = os.urandom(16) # 生成密码学安全的随机密钥 return base64.b64encode(key).decode('utf-8') @staticmethod def encrypt(plaintext: str, key_base64: str) -> str: """ SM4 CBC模式加密 :param plaintext: 明文字符串 :param key_base64: Base64编码的密钥 :return: Base64编码的字符串，格式为：IV + 密文 """ # 1. 解码密钥 key = base64.b64decode(key_base64) if len(key) != 16: raise ValueError("SM4密钥长度必须为16字节") # 2. 生成随机IV iv = os.urandom(16) # 3. 创建SM4对象并设置参数 crypt_sm4 = sm4.CryptSM4() crypt_sm4.set_key(key, sm4.SM4_ENCRYPT) # 设置密钥和加密模式 crypt_sm4.set_iv(iv) # 设置IV # 4. 执行加密，注意需要将字符串编码为bytes plaintext_bytes = plaintext.encode('utf-8') cipher_bytes = crypt_sm4.crypt_cbc(plaintext_bytes) # 自动进行PKCS#7填充 # 5. 合并IV和密文，然后Base64编码 iv_and_cipher = iv + cipher_bytes return base64.b64encode(iv_and_cipher).decode('utf-8') @staticmethod def decrypt(iv_cipher_base64: str, key_base64: str) -> str: """ SM4 CBC模式解密 :param iv_cipher_base64: Base64编码的字符串（IV + 密文） :param key_base64: Base64编码的密钥 :return: 解密后的明文字符串 """ # 1. 解码Base64字符串 iv_cipher_bytes = base64.b64decode(iv_cipher_base64) # 2. 分离IV和密文 iv = iv_cipher_bytes[:16] cipher_bytes = iv_cipher_bytes[16:] # 3. 解码密钥 key = base64.b64decode(key_base64) if len(key) != 16: raise ValueError("SM4密钥长度必须为16字节") # 4. 创建SM4对象并设置参数 crypt_sm4 = sm4.CryptSM4() crypt_sm4.set_key(key, sm4.SM4_DECRYPT) # 设置密钥和解密模式 crypt_sm4.set_iv(iv) # 设置IV # 5. 执行解密 plaintext_bytes = crypt_sm4.crypt_cbc(cipher_bytes) # 自动移除PKCS#7填充 # 6. 解码为字符串 return plaintext_bytes.decode('utf-8') # 使用示例 if __name__ == '__main__': util = SM4Util() key = util.generate_key() print(f"生成的密钥: {key}") text = "Python端的SM4加密测试数据" encrypted = util.encrypt(text, key) print(f"加密结果: {encrypted}") decrypted = util.decrypt(encrypted, key) print(f"解密结果: {decrypted}") print(f"加解密是否成功: {text == decrypted}")

关键点解析：

• os.urandom(16)：用于生成密码学安全的随机字节，适用于密钥和IV的生成。
• crypt_sm4.crypt_cbc()：gmssl的crypt_cbc方法内部已经集成了PKCS#7填充和移除的逻辑，我们无需手动处理，这大大简化了代码。
• 切片操作iv_cipher_bytes[:16]和[16:]：Python的切片语法非常简洁，用于分离IV和密文。
• 编解码：始终使用UTF-8进行字符串和字节序列的转换，确保与前端、Java后端兼容。

6. 联调测试与常见问题排查实录

即使每一端的代码单独测试都通过了，联调时依然可能问题百出。下面是我在多个项目中总结的排查清单和实战经验。

6.1 联调核心检查清单

当你发现前端加密、后端解密失败（或反之）时，请按以下顺序逐一核对：

6.2 典型问题与解决方案

问题一：Java后端抛出BadPaddingException: pad block corrupted

这是联调中最常见的错误，根本原因在于前后端用于加解密的“数据块”不一致。

• 排查步骤：
  1. 打印长度：在前端，打印出加密后（拼接IV前）的密文字节数组长度。在Java后端，打印出分离后待解密的cipherBytes的长度。这两个长度必须相等，且应该是16的倍数（因为CBC模式和填充）。
  2. 检查填充：确认前端使用的填充方案是pkcs#7，Java后端使用的变换字符串包含PKCS7Padding（注意不是PKCS5Padding，尽管在16字节分组下等价，但算法名称必须匹配BC提供者）。
  3. 核对IV：确认前端是将IV拼在密文之前，而后端是从完整数据块的最前面16字节提取IV。一个字节都不能错。

问题二：解密出的明文开头或结尾有多余字符或乱码

• 可能原因1：IV未正确分离。如果后端错误地将IV的一部分当成了密文，或者前端拼接时顺序错了，就会导致解密出的明文开头是乱码。确保切割索引是正确的[0, 16)和[16, )。
• 可能原因2：字符编码不一致。前端plainText是UTF-8字符串，后端解密后也用UTF-8解码。但如果前端页面编码不是UTF-8，或者后端默认编码是GBK，就会导致中文乱码。强制所有环节使用UTF-8。
• 可能原因3：填充未被正确移除。某些低级API可能需要手动处理PKCS#7填充。在我们的封装中，gmssl和sm-crypto以及Bouncy Castle的PKCS7Padding都是自动处理的。如果你使用了其他库或底层调用，需要检查填充字节的移除逻辑。

问题三：跨语言测试工具结果对不上

有时为了验证，会用在线SM4工具（如你提供的LZL工具）加解密，然后和自己的代码对比。

• 注意点：在线工具通常需要你明确输入IV。如果你的代码是随机IV并拼接的，那么你需要将IV和密文分别Base64编码后，手动填入工具的IV和密文字段进行解密测试。反之，用工具加密时，也要记录下它生成的IV，并在你的解密代码中正确使用。
• 最佳实践：先让你的前端和后端代码，使用一个固定的、已知的密钥和IV进行加解密测试，确保两者自洽。然后再测试随机IV的场景。

6.3 一个完整的联调测试用例

假设我们约定一个固定的密钥和IV（仅用于测试），来验证三端是否一致。

测试向量：

• 密钥 (Hex):0123456789ABCDEFFEDCBA9876543210
• 密钥 (Base64):ASNFZ4mrze/ty6mHZUMhEA==
• IV (Hex):000102030405060708090A0B0C0D0E0F
• IV (Base64):AAECAwQFBgcICQoLDA0ODw==
• 明文:Hello SM4!

测试步骤：

1. 用上述密钥和IV，在LZL在线工具上选择CBC模式、PKCS7填充（如果可选）、输入格式为Text、输出格式为Base64，进行加密。记录下输出的密文（注意工具可能只输出密文，你需要手动将IV和密文拼接）。
2. 用你的前端代码，传入相同的明文、Base64密钥和Base64 IV，执行加密。将输出的Base64字符串与在线工具的结果（或手动拼接IV+工具密文的结果）对比。
3. 用你的Java后端代码，传入前端加密的结果和Base64密钥，执行解密。应得到原始明文。
4. 用你的Python后端代码，重复步骤3。

通过这个固定向量的测试，可以快速定位是哪个环节的算法实现或数据格式处理出了问题。

7. 进阶话题与性能优化

当基础功能跑通后，在实际生产环境中我们还需要考虑更多。

7.1 密钥的安全生命周期管理

静态密钥是最大的安全隐患。一个健壮的密钥管理方案应包括：

• 密钥分发：使用非对称加密（如SM2）在通信初始阶段协商一个临时的会话对称密钥（SM4密钥）。这样每次会话的密钥都不同。
• 密钥存储：后端服务器上的密钥应存储在安全的硬件模块（HSM）或经过加密的配置中心/密钥管理服务（KMS）中，而不是写在配置文件或代码里。
• 密钥轮转：定期更换密钥，即使某个密钥泄露，影响范围也有限。

7.2 选择更安全的工作模式

CBC模式对于大多数场景已足够安全，但它不能提供完整性校验。攻击者可能篡改密文，导致解密出的明文虽然乱码，但系统可能无法察觉。对于要求更高的场景，可以考虑：

• GCM模式：这是一种认证加密模式，能同时提供保密性、完整性和身份验证。遗憾的是，目前一些国密库对SM4-GCM的支持还不完善或不够普及，需要仔细测试所选库的兼容性。
• 手动添加MAC：如果无法使用GCM，可以在CBC加密后，对密文计算一个消息认证码（如HMAC-SM3），将MAC和密文一起传输。接收方先验证MAC，再解密。

7.3 性能考量与最佳实践

• 批量加密：对于大量数据，应分块进行加密。但要注意在CBC模式下，每一块的加密依赖于前一块，因此无法并行加密。如果性能是瓶颈，可以评估使用ECB模式（仅适用于加密非模式化数据，如已压缩或随机化的数据）或CTR模式（如果库支持）。
• 避免加密大对象：对称加密适合加密数据体本身。对于非常大的文件或数据流，考虑使用混合加密：用SM4加密一个随机的文件密钥，再用这个文件密钥去加密实际数据。
• HTTPS是基础：SM4用于加密应用层的数据，而传输层的安全应由TLS/SSL（HTTPS）保障。两者是互补的，HTTPS防止中间人窃听和篡改通信链路，应用层SM4加密则确保数据在服务器存储或转发到其他不受HTTPS保护的系统时仍是安全的。

实现一套完整可用的国密SM4前后端加密方案，关键在于对细节的掌控。从算法模式、填充方式到数据编码、传输格式，任何一个环节的疏忽都会导致联调失败。本文提供的代码方案，经过了多个真实项目的验证，可以直接集成使用。但更重要的是理解其背后的原理和设计思路，这样当遇到新的库、新的语言或特殊需求时，你才能游刃有余地进行调整和优化。安全无小事，在加密这件事上，多花点时间把基础打牢，远比出了问题再补救要划算得多。