前端加密这事，前端很多人第一反应是加密“防君子不防小人”。这话对，前端但不全对。加密真正的前端价值不在于让攻击者彻底无解，而是加密把破解成本抬高到“不值得”的程度。我见过太多团队把用户密码明文丢到localStorage里，前端理由是加密“反正后端有HTTPS”。可一旦XSS漏洞被利用，前端攻击者拿到的加密就是用户的原始口令，连字典都不用跑。前端
最基础也最常被误用的加密是对称加密，比如AES。前端开发者的加密直觉是：前端用密钥加密，后端解密，前端天衣无缝。但密钥放哪？放JS文件里等于白送，放接口里又绕回原点。我见过一个项目把AES密钥硬编码在webpack的配置文件里，结果被爬虫工程师顺着sourcemap扒了个精光。对称加密适合的场景是临时混淆，比如防止用户随手抓包看到明文参数，而不是真正对抗恶意攻击。
稍微进阶一点的是非对称加密，RSA或者ECC。前端用公钥加密，后端拿私钥解密。这解决了密钥分发问题，但代价是性能。RSA加密1024字节的数据就要几毫秒，如果表单字段多，用户能明显感觉到卡顿。有个折中方案是混合加密：先用RSA传一个临时生成的AES密钥，后续数据用AES加解密。这活儿不少大厂都在做，但实现细节坑多——比如随机数生成器如果不够随机，攻击者可能推算出密钥。
还有一类容易忽略的是哈希散列，SHA-256这类。它本质不是加密，而是单向摘要。前端把密码哈希后再传给后端，至少能避免明文在日志里裸奔。但哈希有个致命弱点：如果用户密码是“123456”，攻击者提前算好彩虹表，一眼就能比对出来。所以得加盐，而且盐要随机且足够长。我曾经看到有人直接把用户名当盐，结果两个用户名相同但密码不同的用户，哈希值前缀完全一样，等于没加。
说说实际案例。某电商平台之前做登录接口，前端只用了Base64编码，相当于给数据穿了件透明雨衣。后来被黑产用重放攻击刷优惠券，后端查日志发现所有请求的payload都是同一串字符，这才意识到问题。他们后来改成RSA加密+时间戳防重放，虽然前端性能损耗了大概15%，但黑产的成本直接翻了十倍。
我的个人观察是，前端加密的核心矛盾从来不是算法强度，而是密钥管理和信任边界。只要代码跑在用户浏览器里，就谈不上绝对安全。所以设计时得问自己：这层加密到底防谁？防普通用户误操作，那对称加密就够；防专业抓包，那至少得上非对称；防拖库，那重点应该放在后端存储加密，而不是前端折腾。
最后提一嘴国密算法SM2/SM4。现在不少政企项目强制要求，但前端实现库的质量参差不齐。我踩过坑——某个号称SM4加密的插件，实际用的还是AES的ECB模式，只是换了个名字。选库的时候别只看star数，得自己跑一遍已知明文测试。
加密方式各有适用场景，没有银弹。真正靠谱的做法是前端做基础混淆，后端做严格校验，中间层加风控。你要真遇到那种坚持“前端加密就能保平安”的产品经理，可以反问他一句：那你敢不敢把私钥直接写进JS里？