encodeURIComponent 只应用于 URL 参数值，不可用于完整 URL；正确用法是 key=encodeURIComponent(value)，配合 URLSearchParams 更安全；它仅解决传输层字符歧义，不防范语义注入。
encodeURIComponent 为什么不能直接套用在完整 URL 上
直接对整个 URL 字符串调用 encodeURIComponent 会导致协议、域名、路径分隔符（如 /、:、?）也被编码，比如 https://example.com/api?x=1 会变成 https%3A%2F%2Fexample.com%2Fapi%3Fx%3D1，后端根本无法解析。这不是“编码参数”，而是把整个 URL 当成一个普通字符串乱码了。
它只该用于「URL 的某一段值」，比如查询参数的 value、fragment 中的文本、或动态拼进 href 或 src 的用户输入部分。
- ✅ 正确场景：给
name参数赋值用户昵称"张三<script>"</script> - ✅ 正确场景：构造重定向地址时，把用户传来的
next值安全嵌入 - ❌ 错误场景：对
window.location.href全量编码后跳转 - ❌ 错误场景：把
fetch(url)的url变量整个丢进去
只编码参数值，不碰键名和结构
URL 参数是 key=value 对，encodeURIComponent 只负责把 value 中的危险字符转义，其余部分（包括 =、&、?）必须由你手动保留原样拼接。
常见错误是写成：encodeURIComponent('q=' + userInput)——这会让等号也被编码成 %3D，后端收不到合法参数。
立即学习“前端免费学习笔记（深入）”；
- ✅ 正确写法：
'q=' + encodeURIComponent(userInput) - ✅ 多参数拼接：
'name=' + encodeURIComponent(name) + '&city=' + encodeURIComponent(city) - ✅ 配合
URLSearchParams更稳：const p = new URLSearchParams(); p.set('q', userInput); fetch('/search?' + p)（内部自动调用encodeURIComponent）
它防不住所有注入，只是第一道过滤网
encodeURIComponent 解决的是 URL 层面的字符歧义问题，比如空格变 %20、中文变 %E4%BD%A0、尖括号变 %3C%3E。但它不处理语义层面的风险：
- ⚠️ 它不会阻止
javascript:alert(1)这类伪协议被塞进href或src——那得靠白名单校验协议头 - ⚠️ 它不防止参数被用于拼 SQL 或模板渲染——后端仍需参数化查询和输出编码
- ⚠️ 它对双层解码（如
%253C是%3C的二次编码）无感，服务端若做多次 decode 就可能绕过
换句话说，前端用 encodeURIComponent 是让参数“能安全传输”，不是让它“能安全执行”。后端拿到后依然要当不可信输入对待。
和 encodeURI 的关键区别在哪
两者都编码 URI 组件，但范围不同：encodeURI 保留 /、?、:、@ 等 URL 结构字符；encodeURIComponent 连这些也编码——所以它更激进，也更安全，**专为参数值设计**。
- ✅ 用
encodeURIComponent编码单个参数值，比如userInput = 'a&b=c'→'a%26b%3Dc' - ❌ 别用
encodeURI替代，它放行&和=，会导致参数解析错乱 - ⚠️ 注意：
encodeURIComponent不编码单引号'，在某些老浏览器或非标准上下文中可能引发问题，若用于内联 JS 字符串（如onclick="f('<?php echo $x;?>')"），还需额外 HTML 实体编码
真正容易被忽略的点是：编码只是起点，不是终点。只要参数最终会进 HTML、JS、SQL 或重定向逻辑，每一层都得按上下文做对应防护——URL 编码管不了 DOM 插入，DOM 插入管不了数据库查询。
