encodeURI 与 encodeURIComponent：整条链接和参数值的区别

两个函数只差一件事：保留哪些字符。encodeURI 认为 : / ? & = # 是链接结构的一部分，不转义；encodeURIComponent 认为它们全是数据，一律转义。选错的后果不是报错，而是参数被拆成多个、或者链接直接打不开。

各自的保留集

encodeURI 保留：A-Z a-z 0-9 ; , / ? : @ & = + $ # - _ . ! ~ * ' ( )。它假设输入是一条完整 URL，只处理不能出现在 URL 里的字符（空格、中文等）。

encodeURIComponent 保留：A-Z a-z 0-9 - _ . ! ~ * ' ( )。其余全部转义，包括 / ? : @ & = + $ , ; #。

差别就在中间那十几个字符。记法：要拼进 URL 的「值」用 component，整条「URL」用 encodeURI。

选错的两种典型后果

该用 component 却用了 encodeURI：搜索词是 a&b，encodeURI 不转义 &，拼出来的 ?q=a&b 被服务端解析成两个参数 q=a 和 b。值被截断，还不报错。

该用 encodeURI 却用了 component：整条链接 https://example.com/a 被编码成 https%3A%2F%2Fexample.com%2Fa，浏览器不会把它当链接，服务器也解析不出路径。这种错误通常一眼能看出来，比第一种安全。

最容易被忽略的一条：把链接塞进参数

分享链接、OAuth 回调、支付回跳这类场景，参数值本身是一条完整 URL。正确做法是先用 encodeURIComponent 对整条内层链接编码，再拼到外层参数里：

https://a.com/jump?to=https%3A%2F%2Fb.com%2Fp%3Fx%3D1

如果只对中文部分编码、保留内层的 ? & =，外层解析时会把内层的参数当成自己的参数——这是回跳丢参数最常见的原因。

解码是反过来的，但范围要匹配

decodeURI 不解码保留字符的转义（%23、%2F 原样保留），以免破坏 URL 结构；decodeURIComponent 会把它们还原成字符。

这个工具的整体 URL 模式遵循 decodeURI 的行为，所以你会看到 %23 解码后还是 %23。需要还原这些字符时切到参数组件模式——这不是 bug，是标准行为。