核心目标是增加攻击门槛、防止明文泄露和批量伪造请求；需按场景选aes（整块参数）、rsa（极敏感字段或密钥加密）及签名防篡改，密钥动态下发或派生，叠加参数映射、数值扰动等混淆，并在请求拦截器统一处理。
在接口调用前对敏感请求参数加密，核心目标不是“防破解”，而是增加攻击门槛、防止明文泄露和批量伪造请求。关键在于选对算法、管好密钥、配合服务端协同解密或验签。
选对加密方式：根据场景区分使用
敏感参数加密不是一刀切，要按数据类型和安全等级选择：
- AES 对称加密：适合加密整块业务参数（如用户ID、金额、订单号）。速度快、兼容性好，推荐用 CryptoJS 或 Web Crypto API 的 AES-GCM 模式（带认证，防篡改）。
- RSA 非对称加密：适合加密极敏感字段（如临时 token、支付凭证），或用于加密 AES 密钥本身。前端用公钥加密，后端用私钥解密，避免密钥硬编码风险。
- 签名（非加密，但必须做）：对所有参数（含时间戳、随机 nonce）按字典序拼接后，用密钥 MD5/SHA256 算出 sign。服务端复算比对，防止参数被篡改或重放。
密钥不能写死：动态下发或派生
把 secretKey 直接写在 JS 里等于没加锁。可行方案有：
- 登录成功后，后端返回一个短期有效的 AES 密钥（带过期时间），前端缓存并用于后续请求加密；
- 用用户登录态（如 JWT payload 中的 uid + salt）结合时间戳，通过 PBKDF2 派生出本次会话密钥；
- 首次请求前先调用一个免鉴权的 /api/key 接口，获取一次性的加密密钥（需绑定设备指纹或 session ID）。
加密前预处理：提升混淆强度
单纯加密还不够，建议叠加轻量混淆，让参数结构更难逆向：
- 参数名动态映射：如把 userId 改成 u_7f2a，服务端维护映射表还原；
- 数值型参数加扰动：比如 amount=99.9 → 传 amount=99900 + Math.floor(Math.random()*100)，服务端减去固定偏移再校验范围；
- 注入噪声字段：添加 _t=1725475823&_v=abc8x 等无意义参数，不参与业务逻辑但参与签名计算。
与请求流程无缝集成
别让加密逻辑散落在每个 axios 请求里。统一在请求拦截器中处理：
- 判断接口白名单（如只对 /api/order/create、/api/coupon/use 加密）；
- 提取 data 或 params，执行排序 → 混淆 → 加密 → 签名 → 组装新请求体；
- 把加密后数据塞入 data.enc 或加 header X-Encrypted: true，方便后端识别走解密流程。
不复杂但容易忽略：加密只是纵深防御的一环，必须和服务端的验签、限流、行为风控联动，单靠前端 JS 加密无法替代 HTTPS、权限校验和业务规则保护。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
