Vue 3前端加密实战：六种加密方式原理与工程落地

前端做数据加密这件事，很多同学一开始都是懵的：明明数据最终要发给后端，后端拿到也要解密，那前端加密的意义到底在哪？这问题的答案其实就俩字——降低风险。Vue项目里，不管是登录密码、用户手机号，还是接口请求参数，直接在控制台或抓包工具里以明文方式裸露，等于把家门钥匙挂在门口。加密不是为了防住国家级黑客，而是为了防住那些"顺手牵羊"的低门槛攻击，以及满足等保、合规审计对敏感数据传输的基本要求。

这篇文章我会基于Vue 3 + Vite的技术栈，把六种最常见的数据加密方式从原理到落地全部捋一遍。每种都会给出能直接复制改的业务代码，还会带着讲清楚它们的适用场景、局限性，以及在真实项目里组合使用的思路。适合已经能熟练写Vue组件、想往工程化和安全方向进阶的同学参考。

1. 内容整体设计与思路拆解

1.1 先搞明白：前端加密到底在防什么

很多人一听"前端加密"就嗤之以鼻，觉得前端代码都暴露在浏览器里，加密等于自欺欺人。这种说法有一定道理，但只对了一半。前端加密的定位从来不是"绝对安全"，而是增加攻击成本。

举个很典型的场景：你的登录接口是POST请求，参数是用户名和密码。如果不做任何处理，用户在浏览器里输入密码点击登录，F12打开Network面板，密码清清楚楚躺在Payload里。这时候任何一个能打开浏览器开发者工具的人，都能直接看到用户的密码明文。更糟糕的是，很多人的密码是跨平台复用的，拿到一个明文密码等于拿到了他半个数字身份。

前端加密解决的核心问题有三类：

• 传输层之外的裸奔问题：HTTPS能保证数据在传输过程中不被窃听，但在浏览器到应用层这一端，数据是明文存在于内存和网络面板中的。加密可以让这些环节暴露出来的不再是原始密码。
• 接口被恶意刷的问题：请求参数加上签名机制之后，攻击者即使抓到了请求，修改任何参数都会导致签名校验失败，能挡掉大量低水平的自动化攻击脚本。
• 合规层面的基本要求：现在很多等保测评、隐私合规检查，都会明确要求敏感信息在传输前进行加密处理。前端加密是满足这些审查的红线动作之一。

所以，前端加密解决方案的设计思路应该是：让攻击者拿到数据之后，要付出足够高的代价才能还原出真正有价值的信息。这也是为什么我们要用多种加密方式组合，而不是只上一种。

1.2 六种加密方式的分类与选型逻辑

先给这六种方式归个类，方便理解它们之间的区别：

选型的逻辑其实很直接：先想清楚你要保护什么，再决定用哪种方式。如果只是让密码不在Network面板里裸奔，MD5加盐就够了；如果需要完整加密一段JSON数据体，AES是主流选择；如果还要考虑密钥本身的安全传递，那就得引入RSA做混合加密。

另外需要强调的是，这里说"加密"其实是广义的，从严格意义来讲，Base64和MD5都不算加密算法——前者是编码，后者是摘要。但在前端业务里，它们是被当作"加密手段"来用的，所以我把它们归到这篇文章里统一讲解，同时把各自的真实定位说清楚。

2. 六种常用加密方式逐个击破

2.1 Base64编码：最基础的工具，但别把它当加密用

Base64在Vue项目里的出场频率很高，比如把文件转成Base64预览、把二进制数据塞到JSON里传、处理URL参数编码。它的工作原理是把3个字节（24位）的数据转换成4个可打印字符，每个字符占6位。

用法很简单，浏览器原生就支持：

// 编码 const encoded = btoa('hello world') console.log(encoded) // aGVsbG8gd29ybGQ= // 解码 const decoded = atob(encoded) console.log(decoded) // hello world

但在Vue项目里直接使用btoa有一个很恶心的坑：它对中文支持极差，遇到非Latin1字符直接抛异常。处理中文内容时要先用encodeURIComponent转一下：

// 处理中文的兼容写法 export function base64Encode(str: string): string { return btoa(encodeURIComponent(str).replace(/%([0-9A-F]{2})/g, (_, p1) => String.fromCharCode(parseInt(p1, 16)))) } export function base64Decode(str: string): string { return decodeURIComponent(atob(str).split('').map((c) => '%' + c.charCodeAt(0).toString(16).padStart(2, '0')).join('')) }

我在实际项目中一般用crypto-js的enc.Base64来处理，它对Unicode的支持更省心：

import CryptoJS from 'crypto-js' const encoded = CryptoJS.enc.Base64.stringify(CryptoJS.enc.Utf8.parse('你好，Vue')) const decoded = CryptoJS.enc.Base64.parse(encoded).toString(CryptoJS.enc.Utf8)

重点提醒：Base64相当于是把数据"换了一层马甲"，任何拿到编码结果的人都能轻易解码还原。它适合用来做数据传输格式转换，但绝不适合用来保护密码这类敏感信息。文章标题里把它列成加密方式之一，是因为业务中它经常作为加密链路的第一个环节出现，但要清醒认识到它的短板。

2.2 MD5加盐：不可逆的"数字指纹"，防篡改利器

MD5是一种哈希算法，输入任意长度的数据，输出固定128位（32个十六进制字符）的摘要。它的关键特性是单向不可逆，也就是你没法从摘要反推出原始内容。

但它有个明显的缺陷：对相同输入永远生成相同摘要。这就意味着攻击者可以提前准备好彩虹表——把常见密码的MD5值都算出来——然后一比对，明文密码就直接暴露了。所以MD5的正确用法是加盐（salt），就是在原文后面拼接一段只有前后端约定的随机字符串，再做哈希。

npm install crypto-js

看一下Vue里的封装写法：

import CryptoJS from 'crypto-js' // 加盐MD5 export function md5WithSalt(content: string, salt: string = 'vue-advanced-2024') { return CryptoJS.MD5(content + salt).toString() } // 使用示例：登录时对密码做加盐MD5 const passwordHash = md5WithSalt(loginForm.password) request.post('/api/login', { username: loginForm.username, password: passwordHash })

不过我要泼一盆冷水：MD5本身已经被证明存在碰撞风险，业界不建议用于安全性要求高的场景。如果后端团队没有强制的MD5要求，我更推荐直接用SHA-256替代MD5，这也是为什么下一节要单独讲SHA系列的原因。

MD5在Vue项目里还有个高频用途是生成缓存版本号——把JSON数据、文件内容做一个MD5摘要，作为缓存Key的一部分，内容变了摘要就变，缓存自动失效，这个场景下MD5依然很好用。

2.3 SHA-256：比MD5更稳的摘要算法

SHA家族里，SHA-256是现在应用最广泛的哈希算法之一，输出256位摘要（64个十六进制字符），碰撞难度远高于MD5。SHA-256和MD5同属哈希算法，但安全性等级不同，在等保测评里SHA-256基本是被认可的基础算法。

import CryptoJS from 'crypto-js' // SHA-256 基础用法 export function sha256(content: string): string { return CryptoJS.SHA256(content).toString() } // 加盐版 export function sha256WithSalt(content: string, salt: string = 'vue-salt-2024') { return CryptoJS.SHA256(content + salt).toString() }

实际操作中，我会把SHA-256用在接口请求参数签名上。思路是：把请求参数按key排序，拼成字符串，加盐，再做SHA-256，得到sign值放到请求头里。后端用同样的规则计算一遍，比对两个sign是否一致，如果不一致就拒绝请求。这样攻击者一旦篡改了参数，sign就会对不上，请求直接被拦截。

// 请求签名示例 function generateSign(params: Record<string, any>, secretKey: string) { const sortedKeys = Object.keys(params).sort() const rawStr = sortedKeys.map((key) => `${key}=${params[key]}`).join('&') return sha256WithSalt(rawStr, secretKey) } // 在请求拦截器中使用 service.interceptors.request.use((config) => { const params = config.params || {} config.headers['X-Sign'] = generateSign(params, 'my-secret-key') return config })

这里有个容易踩坑的点：签名用的参数串必须和后端约定的完全一致。比如参数值是否需要URL解码、空值怎么处理、嵌套对象怎么序列化，这些细节如果不统一，前后端算出来的sign永远对不上，排查起来非常痛苦。

2.4 AES对称加密：大数据量加密的主力方案

AES是当前最主流的对称加密算法，密钥长度支持128位、192位、256位。所谓对称加密，就是加密和解密使用的是同一个密钥。它的优点是性能极好，加密几KB、几MB的数据几乎没有明显延迟，适合加密完整的请求体或响应体。

在Vue项目里，最常用的是crypto-js提供的AES实现。需要特别注意的是，AES有多种工作模式、填充方式和偏移量（IV）设置，前后端必须保持完全一致才能正确解密。

import CryptoJS from 'crypto-js' // 定义一个统一的加解密工具 const AES_KEY = CryptoJS.enc.Utf8.parse('16位或32位密钥字符串') const AES_IV = CryptoJS.enc.Utf8.parse('16位偏移量字符串') export function aesEncrypt(content: string): string { const encrypted = CryptoJS.AES.encrypt(CryptoJS.enc.Utf8.parse(content), AES_KEY, { iv: AES_IV, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }) return encrypted.toString() } export function aesDecrypt(encryptedContent: string): string { const decrypted = CryptoJS.AES.decrypt(encryptedContent, AES_KEY, { iv: AES_IV, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }) return decrypted.toString(CryptoJS.enc.Utf8) }

这段代码里有几个关键点必须清楚：

• mode: CBC是最常用的分组模式，每个明文块先与前一个密文块异或再加密，安全性比ECB高，但需要IV偏移量。
• padding: Pkcs7用于处理最后一个不满16字节的数据块，填充到16字节的整数倍。Java后端的AES实现里常见的是PKCS5Padding，实际上PKCS5和PKCS7在AES下行为一致，可以互通。
• 密钥和偏移量必须是WordArray类型，直接传字符串会导致加解密结果不符合预期，这是新手最容易踩的坑。

AES的最大问题在于密钥怎么安全传递。前端代码是公开的，密钥写死在JS里，等于钥匙和锁放在一起。所以AES适合用在"密钥可以通过后端接口动态下发"的场景，或者用于加密那些不涉及核心敏感数据的业务字段。

2.5 RSA非对称加密：解决密钥传递的"信箱方案"

RSA是非对称加密，里面涉及一对密钥：公钥负责加密，私钥负责解密。公钥可以公开分发，任何人拿到公钥都能加密数据，但只有持有私钥的后端才能解密。这就像街头邮筒——任何人都能往里投信，但只有邮局工作人员拿着钥匙才能打开邮筒取信。

在Vue项目里，RSA最典型的应用场景就是登录密码加密：前端用后端下发的公钥把密码加密，后端用私钥解密。即使公钥被任何人看到，也无法反推私钥，密码就能在传输过程中得到保护。

npm install jsencrypt

用法如下：

import JSEncrypt from 'jsencrypt' // 假设公钥由后端接口下发，存在store里 const publicKey = store.state.publicKey export function rsaEncrypt(content: string, key: string): string { const encryptor = new JSEncrypt() encryptor.setPublicKey(key) return encryptor.encrypt(content) } // 使用示例 const encryptedPassword = rsaEncrypt(loginForm.password, publicKey) request.post('/api/login', { username: loginForm.username, password: encryptedPassword })

RSA的短板也很明显：加密性能差、明文长度限制严格。1024位的RSA密钥最多只能加密117字节的明文，2048位密钥最多只能加密245字节。所以RSA绝对不适用于加密整段JSON请求体，只能加密密码、身份证号这类短小的敏感字段。

这里还有一个工程细节：加密结果在不同实现里的格式可能不同。jsencrypt输出的Base64密文，Java后端的Cipher默认模式是"RSA/ECB/PKCS1Padding"，是可以直接对接解密的。但如果你用的是其他库，一定要确认填充模式，否则会出现前端能加密、后端解不开的惨案。

2.6 AES+RSA混合加密：进阶项目的"标准答案"

既然AES速度快但密钥传递不安全，RSA安全但性能差、长度受限，那很自然的思路就是把两个结合起来：用RSA加密AES的密钥，用AES加密业务数据。这就是混合加密方案。

整体流程是这样的：

1. 前端随机生成一个AES密钥（比如32位随机字符串）。
2. 用这个AES密钥加密请求体数据。
3. 用后端下发的RSA公钥加密AES密钥本身。
4. 把加密后的数据体和加密后的AES密钥一起发给后端。
5. 后端先用RSA私钥解密出AES密钥，再用AES密钥解密业务数据。

Vue里的实现大致长这样：

import CryptoJS from 'crypto-js' import JSEncrypt from 'jsencrypt' export function hybridEncrypt(content: string, rsaPublicKey: string) { // 1. 随机生成AES密钥 const aesKey = CryptoJS.lib.WordArray.random(16).toString() // 2. AES加密业务数据 const encryptedData = CryptoJS.AES.encrypt(content, CryptoJS.enc.Utf8.parse(aesKey), { mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7, iv: CryptoJS.enc.Utf8.parse('0123456789abcdef') }).toString() // 3. RSA加密AES密钥 const encryptor = new JSEncrypt() encryptor.setPublicKey(rsaPublicKey) const encryptedAesKey = encryptor.encrypt(aesKey) return { encryptedData, encryptedAesKey } }

这方案很优雅，但也有需要权衡的地方：每次请求都要做一次RSA加密，虽然只加密很短的AES密钥，但RSA计算本身还是比AES慢一个数量级。在登录、支付这类低频敏感接口上用这个方案完全没问题，但如果是高频的业务查询接口，性能损耗就值得评估了。

我在真实项目里更常用的折中做法是：AES密钥不每次随机生成，而是定时轮换，比如一小时换一次，前端从后端接口获取AES密钥时走一次RSA加密，后续请求直接用AES加密。这样既控制了RSA的计算次数，又保证了密钥不会长期不变。

3. 在Vue 3项目中完整落地：登录加密与接口签名实战

3.1 搭建依赖与工具模块

先把需要用到的依赖装上：

npm install crypto-js jsencrypt

然后创建一个src/utils/crypto.ts，把所有加密方法统一封装起来。为什么单独建一个文件？因为加密逻辑是横切关注点，散落在各个组件里会导致维护成本极高，集中封装后，后续更换算法（比如从MD5换到SHA-256）只改一个文件。

import CryptoJS from 'crypto-js' import JSEncrypt from 'jsencrypt' const SECRET_KEY = 'your-aes-key-16bit' const SECRET_IV = 'your-aes-iv-16bit' // Base64 export const base64Encode = (str: string) => CryptoJS.enc.Base64.stringify(CryptoJS.enc.Utf8.parse(str)) export const base64Decode = (str: string) => CryptoJS.enc.Base64.parse(str).toString(CryptoJS.enc.Utf8) // MD5 加盐 export const md5Encode = (str: string, salt = 'vue-advanced') => CryptoJS.MD5(str + salt).toString() // SHA-256 加盐 export const sha256Encode = (str: string, salt = 'vue-advanced') => CryptoJS.SHA256(str + salt).toString() // AES 对称加解密 export const aesEncrypt = (str: string) => { return CryptoJS.AES.encrypt(CryptoJS.enc.Utf8.parse(str), CryptoJS.enc.Utf8.parse(SECRET_KEY), { iv: CryptoJS.enc.Utf8.parse(SECRET_IV), mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }).toString() } export const aesDecrypt = (str: string) => { return CryptoJS.AES.decrypt(str, CryptoJS.enc.Utf8.parse(SECRET_KEY), { iv: CryptoJS.enc.Utf8.parse(SECRET_IV), mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }).toString(CryptoJS.enc.Utf8) } // RSA 非对称加密 export const rsaEncrypt = (str: string, publicKey: string) => { const encryptor = new JSEncrypt() encryptor.setPublicKey(publicKey) return encryptor.encrypt(str) }

封装好之后，组件里只需要import { rsaEncrypt } from '@/utils/crypto'，不用关心底层是JSEncrypt还是crypto-js，也不需要记住CBC、Pkcs7这些配置，这才是工程化该有的样子。

3.2 场景一：登录密码加密落地方案

登录是加密需求最刚的场景。我常用的方案是RSA加密密码，因为密码是短字段，长度限制完全够用。

后端提供一个获取公钥的接口，前端在登录页加载或用户点击登录时获取公钥：

<script setup lang="ts"> import { ref, onMounted } from 'vue' import { rsaEncrypt } from '@/utils/crypto' import { getPublicKeyApi, loginApi } from '@/api/auth' import type { LoginForm } from '@/types/auth' const loginForm = ref<LoginForm>({ username: '', password: '' }) let publicKey = '' onMounted(async () => { // 从后端获取RSA公钥 const res = await getPublicKeyApi() publicKey = res.data.publicKey }) async function handleLogin() { if (!publicKey) { console.error('公钥尚未加载') return } // 密码先做RSA加密再提交 const encryptedPassword = rsaEncrypt(loginForm.value.password, publicKey) await loginApi({ username: loginForm.value.username, password: encryptedPassword }) } </script>

这里有个容易被忽略的体验问题：用户点了登录按钮，但公钥还没从接口返回，这时候点击登录就会失效。所以我会在获取公钥期间禁用登录按钮，或者在公钥为空时给出明确提示，而不是等着用户莫名其妙点了一次没反应。

3.3 场景二：请求参数全量签名

更进阶的做法是给所有请求参数加签名，防止参数在传输过程中被篡改。在axios拦截器里统一加签名，不污染业务代码：

import axios from 'axios' import { sha256Encode } from '@/utils/crypto' const service = axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL, timeout: 15000 }) const SIGN_SALT = 'interface-signature-salt' // 签名生成规则：参数名按ASCII码排序，拼成 key=value&key=value，最后加盐做SHA-256 function generateSignature(params: Record<string, any>): string { const sortedKeys = Object.keys(params).sort() const rawString = sortedKeys .filter((key) => params[key] !== undefined && params[key] !== null) .map((key) => `${key}=${encodeURIComponent(params[key])}`) .join('&') return sha256Encode(rawString, SIGN_SALT) } service.interceptors.request.use((config) => { const method = config.method?.toUpperCase() let params: Record<string, any> = {} if (method === 'GET') { params = config.params || {} } else if (method === 'POST' || method === 'PUT') { params = config.data || {} } const timestamp = Date.now().toString() const nonce = Math.random().toString(36).substring(2, 15) const signParams = { ...params, timestamp, nonce } const signature = generateSignature(signParams) config.headers['X-Timestamp'] = timestamp config.headers['X-Nonce'] = nonce config.headers['X-Sign'] = signature return config })

加timestamp和nonce的目的是防重放攻击。如果没有这两个字段，攻击者抓到一个合法请求后，可以原封不动地反复提交。加上时间戳和随机数之后，后端可以校验时间戳是否在有效窗口内，以及nonce是否已经使用过，这样重放攻击基本就废了。

这个方案的签名规则看起来简单，但前后端对接时的坑最多。我曾经因为encodeURIComponent对空格的处理方式和后端不一致，排查了整整一个下午。建议在项目初期就把签名规则写成设计文档，前后端各存一份，避免口头约定导致的偏差。

3.4 场景三：敏感数据本地存储加密

除了网络传输，本地存储也是敏感信息泄露的重灾区。有些开发同学会把用户手机号、身份证号直接存在localStorage里，一旦用户电脑中木马或者浏览器被注入脚本，这些数据就全裸了。

用AES加密后再存，能挡掉很大一部分风险：

export function setEncryptedStorage(key: string, value: any) { const jsonStr = JSON.stringify(value) const encrypted = aesEncrypt(jsonStr) localStorage.setItem(key, encrypted) } export function getDecryptedStorage<T>(key: string): T | null { const encrypted = localStorage.getItem(key) if (!encrypted) return null try { const decrypted = aesDecrypt(encrypted) return JSON.parse(decrypted) as T } catch (e) { // 解密失败，说明数据可能被篡改或密钥已更换 localStorage.removeItem(key) return null } }

这里要注意：localStorage自带的XSS防护能力是零，加密只是增加了一层障碍，并不能从根本上解决XSS问题。要真正防住XSS，还得配合CSP（内容安全策略）、对用户输入做严格转义过滤，多管齐下才行。

4. 常见问题与排查技巧实录

4.1 前端加密了，后端解不开

这是最让人头秃的问题。我自己的排查顺序一般是这样的：

1. 确认算法模式是否一致。AES的Mode、Padding、IV必须逐一核对，一个不match就全废。Java后端默认的AES是ECB模式不带IV，而前端我习惯用CBC带IV，这俩直接对不上。
2. 确认密钥/IV的编码方式是否一致。前端用的是UTF-8字符串Parse成WordArray，后端是不是也按UTF-8处理？有些后端代码里Key是Hex或Base64编码的，那前端就得对应调整。
3. 确认密文格式。crypto-js的toString()输出的是OpenSSL格式的Base64字符串，里面可能带着U2FsdGVkX1开头的前缀，后端如果按标准Base64处理会出问题。这时候可以考虑用CryptoJS.enc.Base64.stringify(encrypted.ciphertext)直接输出纯密文Base64。

给大家存一份排查自检清单：

4.2 RSA加密长度报错或结果为空

jsencrypt加密时，如果明文超过密钥长度限制，不会报错，而是直接返回false。遇到加密结果为false或空字符串，别急着怀疑代码，先检查是不是明文太长了。

2048位RSA密钥，最多只能加密245字节。一个中文字符在UTF-8编码下占3个字节，所以最多也就加密80多个汉字。如果确实需要加密长文本，解决方案是改成混合加密方案——RSA只加密AES密钥，长文本交给AES处理。

另外还要检查公钥格式。jsencrypt要求公钥必须是-----BEGIN PUBLIC KEY-----包裹的PKCS#8格式，如果后端给的是不带换行的裸公钥字符串，需要手动补全格式：

function formatPublicKey(key: string): string { return `-----BEGIN PUBLIC KEY-----\n${key.match(/.{1,64}/g)?.join('\n')}\n-----END PUBLIC KEY-----` }

4.3 MD5加盐还是被猜出来了

如果你用的是固定盐值，比如'vue-advanced'这种硬编码字符串，那这个盐其实没啥防护价值。因为盐就写在前端代码里，攻击者反编译一下就能拿到。

更合理的做法是动态盐：盐值由后端生成下发，每个用户拥有独立的盐，或者每次登录使用不同的盐。这样即使攻击者拿到摘要，也无法通过预计算的彩虹表反推密码，因为每个用户/每次请求的盐都不一样。

后端下发的盐可以通过HTTPS传输，配合前端加盐算法，安全性会有一个质的提升。但要注意，盐值一旦下发，需要和后端的密码校验逻辑配合——后端的比对逻辑一般是把用户输入的密码和盐拼接后做同样的哈希，再和数据库里的摘要比对。这个规则一定要前后端对齐。

4.4 加密后性能明显下降

前端加密导致的性能问题，绝大多数出在RSA上。有一次我在一个高频请求的接口上用了RSA加密整个参数对象，页面卡得没法看。后来改成只加密核心敏感字段（比如手机号），其他参数明文传输，体感立刻就流畅了。

另外，jsencrypt本身是纯JS实现，RSA加密大文本时性能尤其差。如果一定要加密长内容，可以考虑使用Web Crypto API（浏览器原生提供），它底层是原生实现，性能比纯JS库好很多。但这API的语法比较底层，封装成本高，需要权衡项目周期。

如果是AES加密导致性能问题，多半是加密的数据量太大——比如把整个大文件、大图片的Base64都拿去AES加密，这就会明显拖慢页面。这种情况应该考虑在前端做分片上传，后端再对每个分片解密处理，而不是在前端一把梭。

4.5 前后端签名永远对不上

签名对不上，八成是参数序列化规则不一致。比如前端把参数值做了encodeURIComponent，后端解析时没有做对应的URL解码；或者前端把空值过滤掉了，后端却把空值也拼接进了签名串。

我的建议是，在项目启动阶段就要把签名规则细化到这种程度：

• 参数如何排序（按ASCII码升序，这是行业惯例）。
• 值是否做URL编码，编码规则是什么。
• 值为null、undefined、空字符串时怎么处理。
• 嵌套对象如何序列化——是JSON字符串还是展开成a.b=xx的扁平格式。
• 数组怎么拼接——是用逗号分隔还是key[]=value的形式。

这些规则一旦定下来，就别随意更改。改了前端忘了改后端，或者改了后端忘了改前端，都能让你排查到怀疑人生。

5. 加密方案选型与落地建议

六种方式全部看完之后，最后聊一点我在真实项目里的选型心得。

如果是中小型项目，后端接口已经写好了，没有太多改造空间，那我建议用RSA加密登录密码 + SHA-256请求签名这个组合。RSA解决密码裸奔问题，SHA-256解决参数篡改问题，前后端改动量小，安全性却比裸奔好太多。

如果是新项目，前后端一起设计，那我强烈建议直接上AES + RSA混合加密方案。虽然实现复杂度高一些，但换来的是整体传输内容的机密性——不只是密码，而是完整请求体都被加密。而且这套方案有扩展性，后续如果要做端到端加密，底子是现成的。

如果是安全性要求极高的金融、政务类项目，前端加密只是整个安全体系的一环。HTTPS、证书双向认证、风控系统、后端脱敏存储、数据库加密这些都得配套上，前端加密解决不了系统性的安全问题。

最后说一个很多文章不会提的细节：加密不等于安全，不要把全部筹码押在加密算法上。算法是公开的，密钥才是核心。密钥的生成、存储、轮换、吊销，每一环都可能成为突破口。前端代码再混淆，密钥硬编码在代码里，就等于是把保险柜钥匙贴在了保险柜外面。所以，真正优秀的方案，永远不会让前端的密钥成为系统安全的唯一支柱。

这篇文章里所有代码片段，我在项目里都实际跑过，可以直接复制改造。踩过的坑也都老老实实写出来了，希望帮大家少走点弯路。如果后端的同事跟你扯"前端加密没意义"，把文章里讲的风险场景和混合加密方案甩给他，实践出真知，跑一次抓包对比，他心里就有数了。