1. 项目概述：为什么要在登录场景拥抱国密？

最近在重构一个老项目的登录模块，客户明确要求对传输的密码进行国密算法改造。这已经不是第一次遇到类似需求了，随着数据安全合规性要求越来越高，尤其是在一些对数据主权有明确要求的行业，用国密算法（SM2/SM3/SM4）替换掉传统的RSA、MD5、SHA-256，正从一个可选项变成一个必选项。我这次接手的项目是一个典型的Spring Boot后端 + Vue前端的分离架构，目标就是把用户登录时“密码加密传输”这个环节，从原来的RSA + MD5组合，平滑替换成SM2非对称加密 + SM3哈希算法的组合。

听起来只是换几个算法库？如果你真这么想，那坑已经在前面等着你了。从算法库的选型、前后端密钥的生成与管理、加密签名的流程设计，到各种异常情况的兼容处理，每一步都有细节需要注意。网上能找到的代码片段往往只解决了“怎么调通API”的问题，但离一个能在生产环境稳定运行、具备良好可维护性的解决方案，还差得很远。这篇文章，我就结合这次实战，把从技术选型到代码落地，再到线上避坑的完整过程拆解给你看，目标就是让你看完之后，能直接照着步骤在自己的项目里复现，并且完美避开我踩过的那些坑。

2. 核心需求与方案设计拆解

2.1 传统登录加密流程的痛点分析

在讨论国密方案之前，我们先回顾一下一个典型的前后端分离登录流程中，密码是如何被处理的。最常见的一种模式是：前端使用RSA公钥加密密码，后端用RSA私钥解密，然后再将解密后的明文密码进行MD5或SHA-256哈希，最后与数据库存储的哈希值比对。

这个流程存在几个潜在问题：

1. 算法依赖：RSA和SHA-256是国际通用算法，在某些特定行业和场景下，使用国密算法是合规性要求。
2. 性能考量：在同等安全强度下，SM2算法的密钥长度更短（256位对比RSA 2048位），加解密和签名验签速度通常更有优势。
3. 哈希强度：MD5早已被证明不安全，SHA-256虽然目前安全，但SM3作为国密哈希算法，其抗碰撞性等指标有专门设计，且更适配国内的安全生态。

我们的核心需求很明确：在不改变现有登录业务逻辑（即后端最终仍需比对密码哈希值）的前提下，将前端的非对称加密算法从RSA替换为SM2，将后端的哈希算法从MD5/SHA-256替换为SM3。

2.2 国密登录方案的整体架构设计

基于上述需求，我设计了如下方案，这个方案的关键在于“平滑替换”和“前后端协同”：

前端 (Vue) 职责：

1. 登录时，从后端获取SM2公钥。
2. 用户输入密码后，前端使用SM2公钥对密码进行加密，得到密文。
3. 将密文作为password参数，发送登录请求给后端。

后端 (Spring Boot) 职责：

1. 启动时生成或读取SM2密钥对（公钥&私钥），并提供接口暴露公钥给前端。
2. 接收到登录请求后，使用SM2私钥解密前端传来的密码密文，得到密码明文。
3. 对密码明文使用SM3算法进行哈希计算。
4. 将SM3哈希值与数据库中预先存储的（同样由SM3计算得出的）密码哈希值进行比对，验证用户身份。

这个架构看起来清晰，但其中有几个至关重要的设计点：

• 密钥管理：SM2密钥对是核心资产。私钥必须绝对安全地存储在后端，绝不能泄露或传输到前端。公钥则可以安全地暴露。
• 密码存储迁移：对于已存用户，其数据库中的密码哈希值是旧算法（如MD5）生成的。直接切换会导致老用户无法登录。因此必须设计迁移策略，通常是在用户首次成功用新算法登录后，用SM3重新计算并更新其数据库中的密码哈希值。
• 算法库一致性：前后端使用的SM2/SM3算法库必须兼容，确保加密、解密、哈希的结果一致。这是最大的坑点之一。

3. 技术选型与核心工具解析

3.1 后端（Spring Boot）国密算法库选型

Java生态中国密算法的实现，首推Bouncy Castle（BC）库。它是一个强大的密码学提供者，完整支持了SM2、SM3、SM4等国密算法。

为什么选Bouncy Castle？

1. 事实标准：在Java密码学体系（JCA）中，BC是应用最广泛、最成熟的第三方提供者，社区活跃，文档相对齐全。
2. 官方支持：国密算法在BC库中已有稳定实现，无需自己再造轮子，安全性和可靠性有保障。
3. 集成方便：通过Maven或Gradle引入依赖即可，然后将其注册为JVM的安全提供者。

具体依赖与初始化：在你的pom.xml中添加依赖。注意，我们使用支持JCA的轻量级API包bcprov-jdk18on。

<dependency> <groupId>org.bouncycastle</groupId> <artifactId>bcprov-jdk18on</artifactId> <version>1.78</version> <!-- 请使用最新稳定版 --> </dependency>

应用启动时，需要在某个配置类中静态注册Bouncy Castle提供者：

import org.bouncycastle.jce.provider.BouncyCastleProvider; import java.security.Security; @Configuration public class CryptoConfig { static { // 防止重复注册 if (Security.getProvider(BouncyCastleProvider.PROVIDER_NAME) == null) { Security.addProvider(new BouncyCastleProvider()); } } }

注意：这个静态代码块只需执行一次。我习惯把它放在一个独立的配置类里，确保在Spring容器初始化任何密码学操作之前，提供者已经就绪。

3.2 前端（Vue）国密算法库选型

前端的选择比后端更复杂，因为浏览器的JavaScript环境没有内置国密算法。我们需要一个纯JS实现的库。经过一番调研和测试，我最终选择了sm-crypto。

为什么选 sm-crypto？

1. 纯JavaScript实现：不依赖任何本地库或插件，兼容所有现代浏览器和Node.js环境，非常适合Vue/React等前端框架。
2. 功能完整：它实现了SM2、SM3、SM4，且API设计简洁明了，与后端Bouncy Castle的交互经过验证是兼容的。
3. 社区认可：在Github上有相当的Star数，且持续维护，issue反馈相对活跃。

安装与引入：通过npm或yarn安装：

npm install sm-crypto --save # 或 yarn add sm-crypto

在Vue组件中按需引入：

import { sm2, sm3 } from 'sm-crypto';

3.3 密钥的生成与管理策略

密钥的安全管理是系统的基石。这里有两种主流策略：

策略一：静态密钥对在应用启动时生成一对SM2密钥（或使用预先生成好的），将公钥配置给前端，私钥加密后保存在后端配置文件或环境变量中。这种方式简单，但密钥长期不变，存在一定的风险。

策略二：动态会话密钥对为每个会话（或每个登录请求）动态生成一对临时的SM2密钥。前端每次登录前先请求一个本次会话专用的公钥，后端生成密钥对后，将公钥返回前端，私钥在内存中缓存（可设置短时过期）。登录验证完成后，立即销毁该私钥。这种方式更安全，但实现稍复杂，对后端性能有一定要求。

对于大多数内部管理系统或对安全性要求不是极端高的场景，策略一（静态密钥）完全够用，且实现简单。本文也将以静态密钥为例进行演示。如果你需要动态密钥，可以在理解静态方案后，自行扩展。

如何生成SM2密钥对？你可以使用后端Java代码生成，也可以使用OpenSSL（如果编译了国密支持）或在线工具先生成一对Base64编码的密钥。这里给出Java生成示例：

import org.bouncycastle.jce.ECNamedCurveTable; import org.bouncycastle.jce.spec.ECNamedCurveParameterSpec; import java.security.*; import java.util.Base64; public class Sm2KeyGenerator { public static void main(String[] args) throws Exception { // 指定SM2椭圆曲线参数 ECNamedCurveParameterSpec sm2Spec = ECNamedCurveTable.getParameterSpec("sm2p256v1"); KeyPairGenerator kpg = KeyPairGenerator.getInstance("EC", "BC"); kpg.initialize(sm2Spec, new SecureRandom()); KeyPair keyPair = kpg.generateKeyPair(); PublicKey publicKey = keyPair.getPublic(); PrivateKey privateKey = keyPair.getPrivate(); // 转换为Base64字符串，方便存储和传输 String publicKeyBase64 = Base64.getEncoder().encodeToString(publicKey.getEncoded()); String privateKeyBase64 = Base64.getEncoder().encodeToString(privateKey.getEncoded()); System.out.println("公钥(Base64): " + publicKeyBase64); System.out.println("私钥(Base64): " + privateKeyBase64); } }

实操心得：生成的私钥务必妥善保管！不要将其提交到代码仓库。推荐的做法是：将公钥放在前端可访问的配置中（或通过接口动态获取），将私钥放在后端服务器的环境变量、配置中心或加密的密钥管理服务（KMS）中。

4. 后端Spring Boot核心实现详解

4.1 构建统一的密码服务工具类

首先，我们创建一个SmCryptoService，它将封装SM2解密和SM3哈希的核心操作。

import lombok.extern.slf4j.Slf4j; import org.bouncycastle.asn1.gm.GMNamedCurves; import org.bouncycastle.asn1.x9.X9ECParameters; import org.bouncycastle.jcajce.provider.asymmetric.ec.BCECPrivateKey; import org.bouncycastle.jce.spec.ECParameterSpec; import org.bouncycastle.jce.spec.ECPrivateKeySpec; import org.bouncycastle.math.ec.ECPoint; import org.springframework.beans.factory.annotation.Value; import org.springframework.stereotype.Service; import javax.annotation.PostConstruct; import java.math.BigInteger; import java.security.*; import java.util.Base64; @Slf4j @Service public class SmCryptoService { @Value("${sm2.private-key}") private String privateKeyBase64; // 从配置读取Base64私钥 private PrivateKey sm2PrivateKey; /** * 初始化，将配置的Base64私钥字符串转换为PrivateKey对象 */ @PostConstruct public void init() throws Exception { this.sm2PrivateKey = loadPrivateKey(privateKeyBase64); log.info("SM2私钥初始化成功。"); } /** * 加载SM2私钥 */ private PrivateKey loadPrivateKey(String privateKeyBase64) throws Exception { // 1. Base64解码 byte[] privateKeyBytes = Base64.getDecoder().decode(privateKeyBase64); // 2. 将字节数组转换为BigInteger（私钥d值） BigInteger privateKeyD = new BigInteger(1, privateKeyBytes); // 3. 获取SM2椭圆曲线参数 X9ECParameters sm2ECParameters = GMNamedCurves.getByName("sm2p256v1"); ECParameterSpec sm2Spec = new ECParameterSpec( sm2ECParameters.getCurve(), sm2ECParameters.getG(), sm2ECParameters.getN(), sm2ECParameters.getH() ); // 4. 创建私钥规范并生成PrivateKey对象 ECPrivateKeySpec privateKeySpec = new ECPrivateKeySpec(privateKeyD, sm2Spec); KeyFactory keyFactory = KeyFactory.getInstance("EC", "BC"); return keyFactory.generatePrivate(privateKeySpec); } /** * SM2解密 * @param cipherTextBase64 前端传来的Base64格式密文 * @return 解密后的明文 */ public String decryptSm2(String cipherTextBase64) throws Exception { // 注意：sm-crypto默认生成的SM2密文是C1C3C2格式的16进制字符串，并进行了Base64编码。 // 我们需要先Base64解码，再按C1C3C2格式处理。 byte[] cipherData = Base64.getDecoder().decode(cipherTextBase64); // 这里简化处理，实际解密需要根据sm-crypto的加密格式（通常是ASN.1编码或简单拼接）来解析。 // 更通用的做法是使用BC的SM2Engine进行解密。 // 由于篇幅，此处展示使用BC提供的工具类进行解密的更可靠方法。 return decryptWithSm2Engine(cipherData); } /** * 使用BC的SM2Engine解密 (推荐) */ private String decryptWithSm2Engine(byte[] cipherData) throws Exception { // 引入SM2Engine进行解密 org.bouncycastle.crypto.engines.SM2Engine engine = new org.bouncycastle.crypto.engines.SM2Engine(); org.bouncycastle.crypto.params.ECPrivateKeyParameters privateKeyParameters = new org.bouncycastle.crypto.params.ECPrivateKeyParameters( ((BCECPrivateKey) sm2PrivateKey).getD(), new org.bouncycastle.crypto.params.ECDomainParameters( GMNamedCurves.getByName("sm2p256v1").getCurve(), GMNamedCurves.getByName("sm2p256v1").getG(), GMNamedCurves.getByName("sm2p256v1").getN(), GMNamedCurves.getByName("sm2p256v1").getH() ) ); engine.init(false, privateKeyParameters); byte[] decryptedBytes = engine.processBlock(cipherData, 0, cipherData.length); return new String(decryptedBytes, "UTF-8"); } /** * SM3哈希计算 * @param data 原始字符串 * @return SM3哈希值的16进制字符串 */ public String hashSm3(String data) throws Exception { MessageDigest md = MessageDigest.getInstance("SM3", "BC"); md.update(data.getBytes("UTF-8")); byte[] hash = md.digest(); // 转换为16进制字符串 StringBuilder hexString = new StringBuilder(); for (byte b : hash) { String hex = Integer.toHexString(0xff & b); if (hex.length() == 1) { hexString.append('0'); } hexString.append(hex); } return hexString.toString(); } /** * 获取SM2公钥（提供给前端） */ public String getPublicKeyBase64() { // 这里需要根据你的私钥推导出公钥，或者直接从配置读取一个完整的密钥对。 // 简单起见，假设我们配置里也存了公钥，或者通过私钥计算。 // 示例：从配置读取 // return publicKeyBase64Config; // 实际项目中，公钥可以写死在前端，或者通过此接口动态获取。 return "你的SM2公钥Base64字符串"; } }

这个工具类有几个关键点：

1. @PostConstruct确保服务启动后私钥就被正确加载。
2. 私钥的加载过程需要遵循SM2的密钥格式。我们配置中存储的是原始私钥d值的Base64编码。
3. decryptWithSm2Engine方法使用了Bouncy Castle底层的SM2Engine，这是与前端sm-crypto库默认加密模式兼容的推荐做法。
4. SM3哈希计算与MD5、SHA-256的API调用方式类似，只是算法名称换成了SM3。

4.2 改造用户登录认证逻辑

接下来，我们需要在用户登录的入口（通常是AuthenticationFilter或LoginController）集成上述工具。

假设我们有一个简单的AuthController：

@RestController @RequestMapping("/api/auth") public class AuthController { @Autowired private SmCryptoService smCryptoService; @Autowired private UserService userService; @PostMapping("/login") public Result login(@RequestBody LoginRequest request) { try { // 1. SM2解密前端传来的密码密文 String plainPassword = smCryptoService.decryptSm2(request.getPassword()); // 2. 根据用户名查询用户 User user = userService.findByUsername(request.getUsername()); if (user == null) { return Result.error("用户不存在"); } // 3. 对解密后的密码明文进行SM3哈希 String inputPasswordHash = smCryptoService.hashSm3(plainPassword); // 4. 与数据库中存储的密码哈希值比对 // 注意：数据库里存储的应该是SM3哈希值。对于老用户，可能是旧算法哈希，需要兼容处理。 if (!inputPasswordHash.equals(user.getPasswordHash())) { // 密码错误，可能是老用户用旧哈希，这里可以尝试一次旧算法验证，实现平滑迁移。 return Result.error("密码错误"); } // 5. 生成JWT Token等后续登录成功逻辑... String token = generateToken(user); return Result.ok("登录成功").data("token", token); } catch (Exception e) { log.error("登录处理异常", e); return Result.error("系统错误"); } } /** * 提供给前端获取SM2公钥的接口 */ @GetMapping("/public-key") public Result getSm2PublicKey() { String publicKey = smCryptoService.getPublicKeyBase64(); return Result.ok().data("publicKey", publicKey); } }

4.3 数据库密码哈希的迁移策略

这是上线过程中必须谨慎处理的一环。你不能直接修改所有用户的密码哈希字段，那会导致所有用户瞬间无法登录。

我采用的“懒迁移”策略：

1. 在用户表user中，保留原有的password_hash字段，同时增加一个password_algo字段，用于标识该密码哈希使用的算法（如md5,sm3）。
2. 用户登录时：
   • 如果password_algo是sm3，直接使用上述SM3哈希比对。
   • 如果password_algo是md5（或其他旧算法），则先用旧算法验证用户输入的密码。
   • 如果旧算法验证成功，立即用SM3算法重新计算用户输入的密码明文，更新password_hash和password_algo为sm3。然后，正常完成本次登录流程。这样，用户下次登录时，就会走新的SM3流程了。
3. 通过这种方式，随着时间推移，所有活跃用户的密码都会自动迁移到SM3算法，无需管理员手动干预，对用户无感。

5. 前端Vue核心实现详解

5.1 封装前端加密工具函数

在前端项目中，我们创建一个utils/crypto.js文件，封装SM2加密和SM3哈希的函数。

// utils/crypto.js import { sm2, sm3 } from 'sm-crypto' /** * SM2加密 * @param {string} plainText 明文 * @param {string} publicKeyBase64 Base64编码的SM2公钥 * @return {string} Base64编码的密文 */ export function encryptWithSm2(plainText, publicKeyBase64) { // sm-crypto的sm2.doEncrypt默认接受16进制公钥和明文，输出16进制密文(C1C3C2格式) // 我们需要将Base64公钥解码为16进制字符串 const publicKeyHex = Buffer.from(publicKeyBase64, 'base64').toString('hex') // 执行加密，加密模式选择'04'（即未压缩格式），这是与后端BC库兼容的常见格式 const cipherTextHex = sm2.doEncrypt(plainText, publicKeyHex, 1) // 第二个参数1代表输出为C1C3C2顺序 // 将16进制密文转换为Base64，便于在JSON中传输 const cipherTextBase64 = Buffer.from(cipherTextHex, 'hex').toString('base64') return cipherTextBase64 } /** * SM3哈希 (前端一般用于其他需要哈希的场景，登录密码哈希通常在后端做) * @param {string} data 原始数据 * @return {string} 16进制哈希值 */ export function hashWithSm3(data) { return sm3(data) } /** * 获取后端公钥并加密密码 * 这是一个集成的便捷函数，用于登录场景 * @param {string} password 用户输入的明文密码 * @return {Promise<string>} 加密后的密码密文(Base64) */ export async function encryptPasswordForLogin(password) { try { // 1. 从后端获取SM2公钥 (假设接口为 /api/auth/public-key) const response = await fetch('/api/auth/public-key') const result = await response.json() if (result.code !== 200) { throw new Error('获取公钥失败') } const publicKeyBase64 = result.data.publicKey // 2. 使用公钥加密密码 const encryptedPassword = encryptWithSm2(password, publicKeyBase64) return encryptedPassword } catch (error) { console.error('密码加密失败:', error) throw error } }

关键点解析：

1. sm2.doEncrypt的第三个参数cipherMode默认为1，代表输出密文为C1C3C2顺序的16进制字符串。这与后端Bouncy Castle的SM2Engine默认解析格式一致，是兼容的关键。
2. 我们最终将16进制密文转为Base64再传输，是为了避免JSON传输中可能出现的编码问题（如特殊字符），Base64是更安全的选择。
3. 前端SM3哈希函数hashWithSm3在这里展示出来，虽然登录流程中密码哈希在后端完成，但其他需要前端哈希的场景（如某些签名）可能会用到。

5.2 集成到登录表单组件

现在，在Vue的登录组件中，我们使用封装好的工具函数。

<template> <div class="login-container"> <form @submit.prevent="handleLogin"> <input v-model="form.username" type="text" placeholder="用户名" /> <input v-model="form.password" type="password" placeholder="密码" /> <button type="submit" :disabled="loading">{{ loading ? '登录中...' : '登录' }}</button> </form> </div> </template> <script> import { encryptPasswordForLogin } from '@/utils/crypto' export default { data() { return { form: { username: '', password: '' }, loading: false } }, methods: { async handleLogin() { if (!this.form.username || !this.form.password) { this.$message.error('请输入用户名和密码') return } this.loading = true try { // 关键步骤：加密密码 const encryptedPassword = await encryptPasswordForLogin(this.form.password) // 发送登录请求，密码字段已经是密文 const response = await this.$axios.post('/api/auth/login', { username: this.form.username, password: encryptedPassword // 注意，这里传的是加密后的字符串 }) if (response.data.code === 200) { this.$message.success('登录成功') // ... 处理登录成功后的逻辑，如存储token、跳转页面 } else { this.$message.error(response.data.msg || '登录失败') } } catch (error) { console.error('登录异常:', error) this.$message.error('网络或系统错误') } finally { this.loading = false } } } } </script>

至此，一个完整的、使用国密SM2加密传输、SM3哈希存储的登录流程，前后端核心代码就串联起来了。

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

理论跑通，代码写完，真正的挑战才刚刚开始——联调。下面是我在联调过程中遇到的最典型的几个问题及解决方案。

6.1 问题一：前端加密，后端解密失败，报“Invalid point encoding”或“Malformed input”错误

问题现象：前端成功加密并发送了密文，但后端在解密时抛出异常，提示无效的点编码或输入格式错误。

排查思路：

1. 检查公钥一致性：确保前端用于加密的公钥，与后端用于解密的私钥是配对的同一对密钥。最稳妥的方式是，后端提供一个接口返回公钥，前端每次都动态获取，而不是在前端写死。
2. 检查密文格式：这是最常见的原因。sm-crypto的doEncrypt默认输出是16进制字符串（C1C3C2顺序）。你需要确认：
   • 前端是否将这个16进制字符串正确转换成了Base64？
   • 后端在解密前，是否对这个Base64字符串进行了正确的解码？
   • 后端SM2Engine初始化时，是否设置了正确的模式（false代表解密）和参数？
3. 检查编码与解码：确保在整个流程中（前端加密后处理、网络传输、后端接收后处理）没有发生意外的字符编码转换（如UTF-8与字节数组的转换错误）。

解决方案： 我写了一个简单的测试方法来验证前后端加解密是否自洽。

后端测试工具类：

public void testSm2Compatibility() throws Exception { String testPlainText = "Hello国密123"; // 1. 使用后端库加密 (模拟前端行为) // 这里需要用到公钥，略。实际上你可以用BC的SM2Engine加密一次。 // 2. 更直接的方法：写一个单元测试，调用你封装好的encrypt方法（如果你有）和decrypt方法 // 确保 encrypt(plainText).equals( decrypt(encrypt(plainText)) ) // 3. 与前端对齐：让前端加密一个固定字符串，将得到的Base64密文给你。 String cipherTextFromFrontend = "前端提供的Base64密文"; String decryptedText = smCryptoService.decryptSm2(cipherTextFromFrontend); System.out.println("解密结果: " + decryptedText); System.out.println("是否一致: " + testPlainText.equals(decryptedText)); }

前端测试脚本：在浏览器控制台或一个测试页面运行：

import { sm2 } from 'sm-crypto' const publicKeyHex = '你的公钥16进制字符串'; // 从后端获取的公钥转换来 const testText = 'Hello国密123'; const encryptedHex = sm2.doEncrypt(testText, publicKeyHex, 1); const encryptedBase64 = btoa(encryptedHex); // 注意浏览器环境用btoa，Node用Buffer console.log('加密后Base64:', encryptedBase64); // 将这个encryptedBase64交给后端，看能否解密出原文。

通过这个“端到端”的测试，可以快速定位是前端加密格式问题，还是后端解密逻辑问题。

6.2 问题二：SM3哈希值比对不上

问题现象：密码解密成功了，但计算出的SM3哈希值与数据库中的值不匹配。

排查思路：

1. 哈希输入是否一致：SM3哈希对输入极其敏感。确保后端计算哈希时，输入的字符串与用户原始输入的密码完全一致，包括首尾空格（通常需要trim掉）、字符编码（必须统一为UTF-8）。
2. 数据库中的哈希值是如何生成的？是新用户注册时由后端SM3计算存入的，还是从旧系统迁移过来的？如果是迁移的，迁移过程是否正确？
3. 哈希输出格式：你计算出的SM3哈希值是16进制字符串吗？长度是否是64位（256位/4）？数据库里存储的格式是否也是同样的16进制字符串？有些数据库可能会以二进制形式存储，需要确认比对时是否做了正确的转换。

解决方案： 编写一个哈希验证工具方法：

public boolean verifyPassword(String inputPlainPassword, String storedHash, String storedAlgo) throws Exception { if ("sm3".equalsIgnoreCase(storedAlgo)) { String computedHash = smCryptoService.hashSm3(inputPlainPassword.trim()); // 注意trim return computedHash.equalsIgnoreCase(storedHash); // 忽略大小写比较 } else if ("md5".equalsIgnoreCase(storedAlgo)) { // 旧算法验证逻辑... String computedMd5 = DigestUtils.md5DigestAsHex(inputPlainPassword.trim().getBytes()); return computedMd5.equalsIgnoreCase(storedHash); } return false; }

并在登录逻辑中，使用user.getPasswordAlgo()来动态选择验证方法。同时，在用户注册或密码修改的逻辑中，确保使用hashSm3方法并正确设置password_algo为sm3。

6.3 问题三：性能与并发考量

潜在风险：SM2非对称加解密是CPU密集型操作。在高并发登录场景下，如果每个请求都进行SM2解密，可能会对服务器CPU造成较大压力。

优化建议：

1. 限流与降级：在网关或应用层对登录接口实施限流，防止恶意攻击。
2. 缓存公钥：前端不应每次登录都请求公钥，可以将公钥缓存到本地（如localStorage），并设置合理的过期时间（如1天）。后端公钥变更时，需有机制通知前端失效缓存。
3. 考虑动态密钥对：如前所述，动态密钥对更安全，但生成密钥对本身也有开销。需要评估在安全性和性能之间的平衡。对于绝大多数应用，静态密钥+限流+缓存已经足够。
4. 监控与告警：监控登录接口的响应时间和服务器CPU使用率，设置告警阈值。

7. 上线部署与后期维护要点

7.1 密钥的安全管理

这是生产环境的红线。

• 私钥：绝不能出现在代码仓库、前端资源或日志中。必须通过环境变量、配置中心（如Apollo, Nacos）或专业的密钥管理服务（如HashiCorp Vault, AWS KMS）来注入。在K8s环境中，可以使用Secret。
• 公钥：可以暴露，但建议也通过配置管理，方便轮换。前端通过接口获取。
• 密钥轮换：制定密钥轮换策略。轮换时，需要同时更新后端配置和前端的公钥获取逻辑。对于已登录的用户，可以允许其会话持续到过期；新登录请求必须使用新密钥。

7.2 兼容性与回滚方案

在灰度发布或全量上线时，必须做好兼容和回滚准备。

• 版本标记：在登录接口的请求头或参数中，可以增加一个版本号（如crypto-version: sm2-sm3），后端根据版本号决定使用哪套解密和验证逻辑。这样可以在出现问题时分流或快速回滚到旧版本（RSA+MD5）。
• 双写验证：在上线初期，可以同时用新旧两套算法验证密码。只有新算法验证成功，才更新数据库中的哈希值。这样即使新算法有问题，旧算法依然能保证用户登录，实现无缝回滚。

7.3 监控与日志

• 详细日志：在加解密和哈希计算的关键步骤，记录详细的日志（注意不要记录密码明文或私钥）。例如，记录“SM2解密成功”、“SM3哈希计算完成”、“密码验证通过/失败”等。这些日志对于排查线上问题至关重要。
• 异常监控：监控SmCryptoService中decryptSm2和hashSm3方法的异常抛出情况。如果短时间内出现大量解密失败异常，可能是前端版本不一致或遭到了攻击。

整个替换过程，从技术调研到平稳上线，我花了大约两周时间，其中大部分时间都花在了兼容性测试和异常处理上。国密算法的集成本身并不复杂，核心在于对细节的把握和对整个加密链路的清晰认识。希望这份“保姆级”指南，能帮你省去我踩坑的时间，顺利在你的Spring Boot + Vue项目中完成国密化改造。