单页应用路由参数应避免明文暴露，推荐服务端签发一次性签名Token替代原始参数；次选对称加密+Base64（需密钥动态下发）或哈希校验（需动态盐值）；根本原则是敏感信息不入URL，改用Cookie、Header或API获取。
在单页应用（SPA）中，路由参数通常以明文形式出现在 URL 中（如 /user?id=123&token=abc），这存在敏感信息泄露、篡改和重放等安全风险。HTML5 本身不提供路由加密能力，但可通过前端编码 + 后端配合的方式实现参数的混淆、签名、加密或令牌化，让 URL 看似随机且不可逆推原始值。
使用对称加密 + Base64 编码（轻量级前端方案）
适用于非高敏场景（如用户 ID、页面类型），要求前后端共享密钥。前端用 AES 或 CryptoJS 对参数对象加密后 base64 编码，拼入路由；跳转后解密还原。
- 安装
crypto-js：npm install crypto-js - 加密示例（Vue Router 路由守卫中）：
this.$router.push(`/secure/${CryptoJS.AES.encrypt(JSON.stringify({id: 1001, tab: 'profile'}), 'my-secret-key').toString()}`) - 解密示例（
beforeRouteEnter或setup中）：
const decrypted = CryptoJS.AES.decrypt(to.params.encrypted, 'my-secret-key');
const params = JSON.parse(decrypted.toString(CryptoJS.enc.Utf8)); - 注意：密钥不能硬编码在前端生产环境，应通过环境变量注入或由后端动态下发（如首次登录返回短期密钥）
服务端签发一次性 Token 替代原始参数
最推荐的安全实践。前端不直接暴露业务参数，而是向后端请求一个带签名、有时效、可绑定用户/设备的一次性 token，再将该 token 作为路由参数（如 /order?tk=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...）。
- 后端生成 JWT 或自定义签名 token（含 payload：
{uid: 123, order_id: "ORD-789", exp: 1717023600}，签名密钥不外泄） - 前端仅负责携带 token 跳转，不解析也不修改
- 路由组件加载时，调用接口校验 token 并获取真实参数（服务端验证签名 + 过期时间 + 黑名单）
- 优势：URL 完全无业务含义，防篡改、防重放、易审计、可快速作废
路由参数哈希校验（防篡改，不防泄露）
若只需防止参数被恶意修改（如 id=123 改为 id=999），可用“参数+盐值”生成签名附在 URL 后，服务端/前端双重校验。
立即学习“前端免费学习笔记（深入）”；
- URL 示例：
/product/123?_s=8a3f5b2e9c1d，其中_s是HMAC-SHA256("123"+"my-salt")的十六进制摘要 - 前端跳转前计算签名并附加；进入路由时重新计算比对，不一致则拒绝渲染或跳转登录页
- 适合内部管理后台等对保密性要求不高、但需保障参数完整性的场景
- 注意：盐值必须保密，不能写死在前端代码里；建议由后端接口返回动态 salt
避免在 URL 中传递敏感参数的根本原则
加密只是补救手段，最佳实践是从设计上规避。以下情况应改用其他方式：
- 用户身份凭证（token、session_id）→ 存入
HttpOnly Cookie或内存变量，通过 Authorization Header 透传 - 订单详情、支付数据 → 先跳转空路由（如
/checkout），再由组件内发起受鉴权保护的 API 获取 - 搜索关键词、筛选条件 → 使用
history.state或 Vuex/Pinia 持久化，配合scrollRestoration保持体验 - 需要分享的深层链接 → 后端生成短链并映射到加密参数，用户点击短链后服务端 302 跳转至真实路由
不复杂但容易忽略：加密路由参数不是为了“看起来安全”，而是为了降低攻击面、满足合规要求（如 GDPR、等保）、建立纵深防御。真正关键的是明确参数用途、分级敏感度，并让前端与后端协同控制流转边界。
