encodeURI 与 encodeURIComponent

浏览器与 Node 里都提供了一对名字很像、语义却不同的全局函数：它们各自「保留不全编码」的字符集合不同。两者都作用于 URI 文本，但假设你处理的字符串属于 更大或更小 的粒度。

encodeURIComponent：编码「单个组件」

用于 查询取值、路径分段、片段标识 以及任何必须以「不透明数据」形式嵌入、不能顺带注入语法标点的字符串：

encodeURIComponent("a/b?c=1&d=2");
// "a%2Fb%3Fc%3D1%26d%3D2"

可以看到 /、?、&、= 都被转义——这样当它被拼回 URI 某个部件时，仍然是 整块数据，不会被误当成真正的分隔。

手工拼查询串更安全的方式是直接用 API：

const q = new URLSearchParams({
  title: "Q&A / Notes",
  next: "https://example.com/a?x=1",
});
q.toString();
// URLSearchParams 采用 application/x-www-form-urlencoded 规则；空格可能变为 +

若非教学演示，应尽量使用 URLSearchParams、路由库或服务端等价物，以避免重复造轮子。

encodeURI：尽量保留 URI 分界符

encodeURI 假设你传入的字符串 已经接近完整 URI，只需要把「整体上不合法或非 ASCII」的字节修好，但仍然希望 /、?、# 等 继续承担结构语义：

encodeURI("https://example.com/résumé?id=1#top");
// https://example.com/r%C3%A9sum%C3%A9?id=1#top

它 不会 把可能只是「数据」的 /、? 等一律转义——因为实现假定它们可能是真正的语法符号。

encodeURI("https://example.com/search?q=a/b");
// 斜杠可能保持原样——若斜杠本应属于取值而非路径分段，就与服务器期望相冲突

经验法则：不要把任意用户正文丢给 encodeURI「一句话搞定」；对每个部件分别处理，取值与分段多用 encodeURIComponent（或由 URL、URLSearchParams 替你处理）。

快速选用表

场景	更合适的做法
单个路径分段里，/ 是数据	对该分段调用 encodeURIComponent
用户粘贴整段未知结构的 URL	用 URL 解析后再分别编码各部分
结构已可靠的整串仅需处理重音符	可能用 encodeURI，但更清晰往往是 分部件规范化
频繁构造查询串	URL + URLSearchParams，避免字符串粘连

decodeURI 与 decodeURIComponent

对称地，解码也必须匹配先前的编码粒度：

decodeURIComponent("100%2525"); // 一次解码后得到 "100%25"；若链路存在二次编码要明确责任边界
decodeURI("http://host/%7Euser"); // 对部分转义解码，但不会破坏仍作为结构的符号位

若编码粒度与解码粒度错配，解码后的文本可能 重新冒出 &、?，从而改写参数解析语义——这在把字符串反射进 HTML、Location、日志过滤规则时都可能引发实际问题。