企业官网建设流程全解析

后端同事丢过来一句话：“登录密码用RSA加密一下再传”。就这么一句话，我从前端拿到的密钥格式不对开始，一路踩到中文乱码、长文本截断、后端解不开，前前后后折腾了小半天才把这条链路跑通。这篇就把这次前端RSA加密实战完整记录下来，从为什么做、库怎么选、密钥怎么处理，到前端怎么写、后端怎么联调、线上排查怎么下手，一次性说清楚。希望能帮到第一次接触前端加密、或者正在跟RSA较劲的朋友少走几个弯路。

1. 为什么前端要做RSA加密，它的边界在哪里

1.1 先说清楚：前端加密防的是谁

RSA属于非对称加密，核心就是一对儿钥匙：公钥负责加密，私钥负责解密。公钥可以随便发给别人，私钥只能自己藏着。放在前端场景里，流程特别直白：前端从后端拿到公钥，用户在输入框里敲完密码，前端用公钥把密码加密成一段密文，再通过HTTP请求发给后端；后端拿到密文后用自己手里的私钥解出明文。

很多人第一反应是“HTTPS不就已经加密了吗，为什么还要再来一层RSA”。这个想法没错，但有个前提：HTTPS保护的是传输链路。也就是说，从你的浏览器到服务器之间这段路是加密的，路上的“行人”（抓包工具、网络嗅探）看不到你发的明文。可实际项目里，数据不一定只在链路上走一遭，还可能经过网关、日志采集、WAF审计、运维排查等等中间环节。这些环节里如果不小心打了明文日志，HTTPS再强也拦不住后面的人直接翻日志看密码。前端RSA的作用，就是把“明文暴露”这件事尽量往前推，让输入框之后、服务器私钥解密之前，数据始终以密文形态存在。

但这不代表前端加密是万能的。有个边界必须想明白：公钥是公开的，所以攻击者完全可以打开浏览器控制台，把公钥拿走，自己写一个脚本，用同一把公钥伪造合法格式的加密请求直接打到后端。换句话说，前端RSA防的是“被动偷看”，防不了“主动伪造”。它能提高攻击门槛，但不能替代服务端校验、限流、风控这些真正的安全手段。我自己接这个需求时，跟后端明确过这个边界：前端加密做的是传输层之上的纵深防御，核心安全责任依然在后端。这一点先跟产品和技术负责人对齐，后面才不会有人觉得“前端加密了，后端就能万事大吉”。

1.2 什么场景下才值得上RSA

不是所有项目都必须上RSA。加密本身有成本：加解密有性能开销，联调有格式对齐的麻烦，密钥还有轮换和管理的复杂度。我这次选择上RSA，是因为项目符合几个典型条件：

• 涉及高敏感字段。登录密码、身份证号、银行卡号、手机号这类信息，一旦明文出现在日志里，性质就变了。
• 接口需要过第三方网关或审计。某次排查线上问题时，我就亲眼在网关日志里看到过明文表单字段，那种感觉相当酸爽。
• 合规自查提了要求。有些等保测评或内部安全规范明确写着“敏感数据传输应采用密码技术进行加密保护”，前端RSA是落地手段之一。

反过来，有些场景就不太适合。比如上传大文件、传输图片视频，RSA加密性能捉襟见肘，应该走HTTPS加对象存储的加密方案；又比如把所有接口参数全都加密一遍，看起来安全，实际上调试成本、性能开销成倍增长，收益却有限。我给自己定的原则是：敏感字段单独加密，非敏感字段保持原样，不要一锅端。

说个具体场景给你感受一下。我们当时那个系统是后台管理端，用户登录时输入账号密码，走HTTPS，按理说链路已经加密了。但某天安全团队做巡检，发现Nginx的access log里记录了POST body部分字段，密码就在里面躺着。这时候再谈“HTTPS已经加密了链路”就没意义了，问题出在应用层日志。于是需求变成了：密码上RSA，保证到达后端业务代码之前，任何中间组件看到的都是密文。所以你看，前端RSA解决的是“明文落地”的恐惧，而不是“链路窃听”的恐惧。搞清楚了这一点，后端同事再丢需求过来时，你就知道怎么跟他掰扯了。

2. 方案选型与核心准备工作

2.1 选库：JSEncrypt 还是 Web Crypto API

前端做RSA加密，主流方案就两个：第三方库JSEncrypt，或者浏览器原生Web Crypto API。两者我都实际用过，说说我的取舍。

JSEncrypt是老牌库，底层基于jsbn实现，特点是简单粗暴。new一个实例，setPublicKey，然后encrypt一把梭，完事了。它默认支持PKCS#1格式的RSA公钥，也就是那种-----BEGIN RSA PUBLIC KEY-----开头的字符串，对老浏览器兼容性也好。如果项目用的是比较旧的脚手架，或者不想折腾Web Crypto那套异步API和密钥导入逻辑，JSEncrypt是最省心的选择。缺点也有：打包体积不小、加密是同步的（长文本加密时主线程会卡顿）、不维护了但能用。

Web Crypto API就不一样了。这是浏览器原生功能，异步执行，不会阻塞主线程，性能比纯JavaScript实现好一个量级。但它用起来绕：你得先把Base64公钥转成ArrayBuffer，再通过crypto.subtle.importKey导入成CryptoKey对象，然后才能调encrypt方法。而且它默认走RSA-OAEP填充模式，跟Java默认的PKCS#1填充不一样，后面联调就容易对不上。生成环境要求也高，非localhost的HTTP环境直接拿不到crypto.subtle，必须HTTPS才行。

两个方案我做了个对比，你直接看表：

我这边的建议是：快速改造、兼容老系统选JSEncrypt；新项目、对性能有要求、全站已上HTTPS的选Web Crypto API。我这次因为接入的后端Java系统默认用PKCS#1，而且项目里有部分老设备浏览器，最终选了JSEncrypt，稳字当头。

2.2 密钥对的生成与正确传递流程

RSA加密不是前端单方面的事，它需要后端先生成一对密钥。正常流程是这样：

1. 后端生成公钥和私钥，私钥留在服务端配置中心或密钥管理系统里。
2. 后端把公钥通过两种方式给前端：一种是放在配置接口里下发，前端启动时拉取；另一种是直接放在前端代码静态资源里。公钥本来就是公开的，放前端代码里不算泄露，但考虑到密钥可能轮换，我一般建议走配置接口下发，这样换密钥不用重新发版。
3. 前端拿到公钥字符串，保存到内存或本地，加密时使用。
4. 后端收到密文后，用私钥解密，然后该验签验签、该入库入库。

这里要特别强调一条红线：私钥绝对不能出现在前端代码、前端仓库、打包产物里。我见过有人图省事，把后端给的private.key文件直接放前端项目里测试，这等于把保险柜钥匙贴在保险柜门上，一旦仓库泄露，整个加密体系直接报废。密钥对的生成，标准做法是用后端环境的openssl命令完成，前端只需要后端提供的那串公钥字符串。

给你一套生成命令，后端同学如果没思路可以直接甩给他：

# 生成2048位私钥，PKCS#8格式（Java直接用这个） openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048 # 从私钥导出公钥，X.509格式 openssl pkey -in private_key.pem -pubout -out public_key.pem # 如果前端用JSEncrypt，需要转成PKCS#1格式的"BEGIN RSA PUBLIC KEY" openssl rsa -in private_key.pem -pubout -RSAPublicKey_out -out public_key_pkcs1.pem

密钥位数强烈建议2048起步，1024已经不建议用于生产环境，4096更安全但加解密性能会明显下降。我这次用的就是2048，平衡了安全性和性能。

2.3 密钥格式与编码的隐藏大坑

密钥格式这个坑，我愿称之为前端RSA联调第一杀手。你从后端那里拿到的公钥，大概率长这样：

-----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA... -----END PUBLIC KEY-----

但JSEncrypt的setPublicKey想认的是另一副面孔：

-----BEGIN RSA PUBLIC KEY----- MIGJAoGBAJ7nUs3UjP9W5Yv8qWtV+yH7L8kSmK3... -----END RSA PUBLIC KEY-----

看出来了吗？一个是BEGIN PUBLIC KEY，一个是BEGIN RSA PUBLIC KEY。前者是X.509 SubjectPublicKeyInfo格式（很多后端语言，尤其是Java，默认导出的是这个），后者是PKCS#1格式（RSAPublicKey），JSEncrypt默认认PKCS#1。如果你直接把Java导出的公钥塞给JSEncrypt，它不会报错，但加密后你发给后端，后端的Cipher.doFinal大概率抛BadPaddingException，因为前端根本没用对公钥信息。

解决办法有两个。一是后端生成时就按PKCS#1格式导出公钥，用前面那行openssl rsa -RSAPublicKey_out命令即可。二是前端做一次格式转换，不过JSEncrypt没提供现成的转换方法，你干脆让后端直接用命令行转好再给你。

还有一个容易忽略的编码坑：公钥字符串里的换行符。后端接口返回时如果直接把换行给吞了，或者前端把换行全去掉，都会导致setPublicKey失败或加密结果不对。稳妥做法是：拿到公钥后先做个trim，去掉首尾空白，不要手动把中间换行全部去掉，-----BEGIN那一行和-----END那一行之间的Base64内容带不带换行其实不影响JSEncrypt解析，但别把标识行的换行也删了。

3. 前端加密的核心实现与细节打磨

3.1 基础版：JSEncrypt 加密流程与代码

选定JSEncrypt之后，实现就非常顺了。先装包：

npm install jsencrypt

如果项目不用npm，也可以用CDN方式直接引全局脚本，老项目改造一般走这条路：

<script src="https://cdn.example.com/jsencrypt.min.js"></script>

然后在前端加密模块里，封装一个统一的加密方法，不要每个页面都new一遍。我是这样写的：

import JSEncrypt from 'jsencrypt'; // 公钥建议从配置接口拉取，这里先硬编码示意 const PUBLIC_KEY = `-----BEGIN RSA PUBLIC KEY----- MIGJAoGBAJ7... -----END RSA PUBLIC KEY-----`; // 单例模式：避免每次加密都重复初始化JSEncrypt实例 let encryptor = null; function getEncryptor() { if (!encryptor) { encryptor = new JSEncrypt(); encryptor.setPublicKey(PUBLIC_KEY.trim()); } return encryptor; } export function rsaEncrypt(plainText) { if (!plainText) return ''; const result = getEncryptor().encrypt(plainText); if (!result) { console.error('RSA加密失败，请检查公钥格式和明文长度'); } return result; }

调用就很简单了，在登录或者提交敏感信息的地方：

const encryptedPwd = rsaEncrypt(passwordInput.value); fetch('/api/login', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ username: usernameInput.value, password: encryptedPwd }) });

这里有个细节：encrypt方法返回的是Base64编码的密文字符串，后端拿到后先Base64解码再解RSA。如果后端跟你说“解出来的是一堆乱码”，大概率就是这一步没对齐——前端把Base64字符串发过去了，后端当成二进制直接用。我后面排查清单里会再提这个问题。

3.2 中文与长文本处理：分段加密的最佳姿势

很多人在RSA加密这条路上翻车，就是在“长文本加密”上。RSA算法本身对明文长度有限制。以2048位密钥、PKCS#1 v1.5填充为例，最长能加密的字节数是：2048 / 8 - 11 = 245字节。那11字节是填充开销。如果明文超过245字节，JSEncrypt直接返回false或者加密结果被截断，后端解密就等着报错吧。

中文就更麻烦了，UTF-8编码下一个汉字占3个字节。算一下：245 / 3 ≈ 81，也就是说，2048位RSA一次最多只能加密约81个汉字。别以为密码只有十几二十个字符就没事，万一加密的是身份证号加姓名加手机号拼在一起的长字符串，轻轻松松超限。

解决方案就是分段加密。前端按字节或者按字符把明文切块，每块分别加密，把多个密文组装成数组发给后端，后端再逐段解密拼接。我写了个按字符长度切分的方法，保证每块不超过安全阈值：

export function rsaEncryptLong(plainText, chunkSize = 80) { if (!plainText) return ''; // 按字符切分，保证每段的字节数不超过245的上限 const encoder = new TextEncoder(); const segments = []; let current = ''; for (const char of plainText) { const test = current + char; if (encoder.encode(test).length > chunkSize * 3) { segments.push(current); current = char; } else { current = test; } } if (current) segments.push(current); const encryptor = new JSEncrypt(); encryptor.setPublicKey(PUBLIC_KEY.trim()); return segments.map(seg => encryptor.encrypt(seg)).join('|SEG|'); }

后端解密时先按|SEG|把密文拆开，逐段解密再拼接成原文。注意分隔符选个不容易冲突的，|SEG|本身就是安全的。

不过我得说实话：分段加密是能用，但体验一般。如果数据量真的大，比如超过几百字节，我更推荐直接切换到RSA+AES混合加密方案，RSA只加密密钥，AES加密业务数据，这样既不牺牲性能，也不受RSA长度限制。这条我在第四部分展开。

3.3 加盐、时间戳与防重放：加密之外还要补什么

RSA解决的是“隐私性”问题，也就是密文不会被直接读出来。但加密不等于防篡改。密文在传输过程中有没有被调包，RSA单独是验证不了的。公钥是公开的，攻击者可以用公钥自己加密一段内容替换掉你发出去的内容，后端私钥照样能把新密文解密出来，如果后端没有二次校验，攻击者就能构造请求。

所以实战里我做三件事加固。

第一，明文拼接固定盐值。前后端约定一个盐字符串，前端加密时把盐和真实数据拼接在一起，比如密码变成password + '|' + salt，后端解密后校验盐必须匹配。这样攻击者直接用公钥伪造密文时，如果不知道盐值，伪造的密文解出来盐对不上，请求就被拒绝了。

第二，时间戳防重放。请求体里带上timestamp字段，RSA加密时把时间戳也一起加密进去。后端解密后检查时间戳跟当前服务器时间的差值，超过比如5分钟就拒绝。这一步能拦住一部分截获密文后反复重放的攻击。

第三，配合服务端限流和设备指纹。登录接口做IP维度和账号维度的限流，前端上报经过哈希处理的设备指纹信息，服务端判断异常登录行为。这些措施组合起来，前端RSA加密才有意义，不然就跟贴了一层窗户纸差不多。

这里也提醒一句：别为了“更安全”把流程搞得过度复杂。盐值怎么分发？如果盐值也放在前端代码里，攻击者把源码抠出来一样能看到。我自己通常只在低频率接口（登录、改密）上用盐值加时间戳，普通敏感字段只做RSA加密就够了。安全是系统性的，不是把某一环叠满Buff就能解决的。

4. 联调、调试与常见问题排查实录

4.1 后端解不开？先对着这份清单找原因

前端RSA加密联调，最大的痛点是“前端明明加密了，后端就是解不开”。我把这次实战里遇到的四个高发问题整理成了一张表，你照着排查，基本能覆盖九成的情况：

Java后端的标准解密写法大概是这样的，你可以转给后端参考：

import javax.crypto.Cipher; import java.security.*; import java.security.spec.PKCS8EncodedKeySpec; import java.util.Base64; byte[] keyBytes = Base64.getDecoder().decode(privateKeyBase64); PKCS8EncodedKeySpec spec = new PKCS8EncodedKeySpec(keyBytes); KeyFactory keyFactory = KeyFactory.getInstance("RSA"); PrivateKey privateKey = keyFactory.generatePrivate(spec); Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding"); cipher.init(Cipher.DECRYPT_MODE, privateKey); byte[] resultBytes = cipher.doFinal(Base64.getDecoder().decode(encryptedBase64)); String plainText = new String(resultBytes, StandardCharsets.UTF_8);

对应到Node.js后端，用内置的crypto模块也可以：

const crypto = require('crypto'); const privateKey = `-----BEGIN PRIVATE KEY----- MIIEvQ...-----END PRIVATE KEY-----`; const buffer = Buffer.from(encryptedBase64, 'base64'); const decrypted = crypto.privateDecrypt( { key: privateKey, padding: crypto.constants.RSA_PKCS1_PADDING }, buffer ); const plainText = decrypted.toString('utf8');

重点看两行：RSA/ECB/PKCS1Padding和RSA_PKCS1_PADDING。这里的PKCS1Padding跟JSEncrypt默认填充是完全对应的。如果后端用的是OAEP，前端要么改填充模式，要么就等着解密报错。加密算法、填充方式、密钥格式、字符集这四个参数，联调一开始就要双方对齐。

4.2 性能问题与RSA+AES混合加密的落地方案

RSA加解密比AES慢得多，这是数学原理决定的，大整数模幂运算就是贵。前端2048位RSA加密，在中端手机上实测大约30到80毫秒，老设备上能到200毫秒以上。单次登录请求多几十毫秒还好，但如果每个请求每个字段都走RSA，前端卡顿、后端CPU飙升，运维就会找上门。

我的建议是分层处理。绝大多数接口走HTTPS就行，只有登录、改密、支付、验证身份等少数接口的敏感字段才上RSA。如果你确实有很多数据要加密保护，那就上RSA+AES混合加密方案——这也是目前主流合规方案。

方案思路是这样：

1. 前端生成一个随机的AES密钥（比如32字节）。
2. 业务明文用AES密钥加密，AES加密快，适合大数据量。
3. AES密钥本身用RSA公钥加密，跟着请求一起发给后端。
4. 后端用RSA私钥解开AES密钥，再用AES密钥解开业务数据。

前端关键代码示意：

async function hybridEncrypt(plainText, publicKey) { // 生成随机AES密钥 const aesKey = crypto.getRandomValues(new Uint8Array(32)); // AES-GCM加密业务数据 const iv = crypto.getRandomValues(new Uint8Array(12)); const encoded = new TextEncoder().encode(plainText); const aesCryptoKey = await crypto.subtle.importKey( 'raw', aesKey, { name: 'AES-GCM' }, false, ['encrypt'] ); const cipherBuf = await crypto.subtle.encrypt( { name: 'AES-GCM', iv }, aesCryptoKey, encoded ); // RSA加密AES密钥 const importedPublicKey = await crypto.subtle.importKey( 'spki', base64ToArrayBuffer(publicKey), { name: 'RSA-OAEP', hash: 'SHA-256' }, false, ['encrypt'] ); const encryptedAesKeyBuf = await crypto.subtle.encrypt( { name: 'RSA-OAEP' }, importedPublicKey, aesKey ); return { aes_key: arrayBufferToBase64(encryptedAesKeyBuf), cipher_text: arrayBufferToBase64(cipherBuf), iv: arrayBufferToBase64(iv) }; }

这个方案要注意几点：AES GCM的IV每次加密必须随机，不能复用；AES密钥只存活在内存里，用完即弃；后端解密时需要用privateDecrypt解出AES密钥后，再createDecipheriv解业务数据。

混合加密的缺点也很明显：前端代码复杂度上去了，后端也要多写一套解密逻辑。所以我给的判断标准是：加密数据量小、频率低，直接用纯RSA；数据量大、接口多，就用混合；两者都不用超过实际安全需求。

4.3 一份可以直接照抄的自检清单

每次做完前端RSA加密，我都会按下面这份清单逐项检查。你也可以把它当成验收标准。

• [ ] 密钥长度不低于2048位，强烈建议直接用2048或4096
• [ ] 私钥只存在于后端环境，前端仓库、代码、打包产物里没有任何私钥相关字符串
• [ ] 前端公钥格式与加密库匹配，JSEncrypt用BEGIN RSA PUBLIC KEY开头
• [ ] 加密前对明文做了长度校验，超长文本走分段加密或混合加密
• [ ] 前后端填充模式一致：JSEncrypt默认PKCS#1 v1.5，Java用RSA/ECB/PKCS1Padding，Node用RSA_PKCS1_PADDING
• [ ] 密文传输统一用Base64字符串，后端先解码再解密，字符集统一UTF-8
• [ ] 敏感字段如密码、身份证号、手机号没有被打印在console、日志或埋点里
• [ ] 登录或关键操作接口做了时间戳校验和重放防护
• [ ] 公钥走接口下发而不是写死在前端代码里（如果写死了，至少确认支持热更新）
• [ ] 生产环境强制HTTPS，RSA加密是纵深防御，不是替代品

这十条看着简单，但每一条都对应真实踩出来的坑。我这次联调，前面几条几乎全中，尤其是公钥格式和填充模式这两个，来回沟通了整整一个下午才把问题定位清楚。

最后分享一点个人体会。RSA加密本身不复杂，复杂的从来都是前后端双方对同一套规范的默契。公钥格式、填充模式、编码方式、分隔符，哪怕有一个对不上，就是白茫茫一片的排查地狱。我后来学乖了，每次接这种需求，第一件事就是找后端要一个“测试明文+预期密文”的样例，先把基准对齐，再开始写业务代码。调试期间，我会直接在浏览器控制台手动调一下JSEncrypt实例，把生成的密文复制到后端的本地脚本里反复验证，确认格式没问题才继续往下走。另外一个小建议：真到了搞不定的时候，别自己闷头折腾，把前端加密后的密文、公钥原文、后端报错堆栈三样东西一次性甩到沟通群里，问题往往几分钟就有答案了。