HTTP重定向时URL参数需用encodeURIComponent()等函数编码以防乱码或截断；敏感参数如token绝不可放URL中，应存服务端临时存储并传temp_id；前端跳转要避免encodeURI()误用及脚本劫持。
HTTP 重定向时 URL 参数怎么安全拼接
直接在 Location 响应头里拼参数最常见，但容易出编码错误或被截断。关键不是“能不能传”，而是“参数值是否会被服务端正确解析”。
- 中文、空格、
&、=这类字符必须用encodeURIComponent()（前端）或对应语言的 URL 编码函数（如 Python 的urllib.parse.quote()）处理，否则服务端收到的是乱码或截断后的片段 - 不要手动拼
?a=1&b=2，尤其当参数来自用户输入——漏编码一个字符就可能让整个跳转失效，甚至引发 XSS（比如参数里含<script></script>且未编码） - 后端生成跳转 URL 时，优先用框架内置的 URL 构造方法（如 Express 的
res.redirect()+ 查询对象，Django 的redirect()接字典），它们默认做编码
Express 中 res.redirect() 怎么传参不丢数据
Express 默认把字符串原样塞进 Location 头，不自动编码，所以你传 res.redirect('/login?msg=登录失败')，浏览器实际收到的是 /login?msg=%E7%99%BB%E5%BD%95%E5%A4%B1%E8%B4%A5 —— 这没问题；但如果手抖写了 res.redirect('/login?msg=' + req.query.msg)，而 req.query.msg 是用户提交的原始值，就危险了。
- 推荐写法：
res.redirect('/login?' + new URLSearchParams({ msg: req.query.msg }).toString())，URLSearchParams自动编码每个值 - 避免写法：
res.redirect(`/login?msg=${req.query.msg}`)—— 没编码，遇特殊字符直接崩 - 如果参数多且逻辑复杂，先用
url.format()或new URL()构造再重定向，比字符串拼接可靠
重定向传敏感参数（如 token、user_id）为什么不能放 URL 里
URL 会留在浏览器地址栏、历史记录、服务端 access log、代理日志、Referer 头里，任何一环都可能泄露。这不是“能不能”，是“该不该”。
- token、session_id、手机号这类字段，绝对不要出现在重定向的查询参数中
- 替代方案：把参数存到服务端临时存储（如 Redis，带过期时间），重定向时只传一个一次性
temp_id，目标页再用它换真实数据 - 如果必须前端携带，改用
POST + form.submit()跳转（配合隐藏域），或者用fetch()提交后再window.location，避开 URL 记录
前端用 window.location.href 跳转时参数丢失的常见原因
看起来只是赋个值，但实际执行时可能被浏览器拦截、被中间件修改、或因编码问题解析失败。
- 检查是否用了
encodeURI()而非encodeURIComponent()—— 前者不编码/ ? & =，会导致 URL 结构错乱 - 确认跳转前没触发其他脚本修改
location（比如某些埋点 SDK 会劫持跳转） - 如果目标页用
URLSearchParams读参，注意它对未编码的空格返回%20，但对已编码的+（旧式编码）识别不了，统一用encodeURIComponent()最稳
参数传得进去不难，难的是每次都能被目标页原样、完整、安全地拿到——漏掉一次编码、多传一个敏感字段、或依赖了不可靠的日志链路，就可能卡住整个流程。
