URL构造函数为何不解码用户名/密码字段？

这个问题确实戳中了URL API里一个容易让人疑惑的设计点！咱们先掰扯清楚这事儿：

首先你观察得没错——URL对象对searchParams会自动解码，但碰到用户名和密码字段就“搞特殊”，这真不是bug，而是WHATWG URL规范（现在浏览器、Node.js这些主流环境实现的都是这套规范）的有意设计，原因主要有两个：

1. 避免歧义，保留原始编码的语义 #

用户信息部分（用户名+密码）里，冒号是用来分隔用户名和密码的关键符号。但问题在于，用户名本身也可能包含冒号啊！比如我想把jimbo:123作为用户名，那为了不让URL构造函数把它拆成用户名jimbo和密码123，就必须把冒号编码成%3A。

如果构造函数自动给你解码了，那拆分用户名和密码的时候就彻底乱套了——它没法区分解码后的冒号到底是原本的分隔符，还是用户名里自带的字符。所以干脆就返回原始的编码字符串，把解码的控制权交给开发者，由你自己决定什么时候解码、怎么处理特殊字符。

2. 适配不同的使用场景 #

对比searchParams的场景：我们用查询参数的时候，几乎都是要直接用解码后的键值对来做业务逻辑，比如获取foo@而不是foo%40来作为参数值。但用户信息的使用场景就复杂多了——有时候你需要直接把原始编码的用户信息拼回URL里，有时候才需要解码后使用。规范里这么设计，是把选择权留给了开发者，而不是替你做决定。

你提到的RFC 3986确实明确说用户信息可以包含百分编码的字符，但WHATWG规范是在RFC基础上做了更贴合实际工程场景的调整，所以才会出现这种看似“不符合RFC预期”的情况。而且这个API是跨环境标准化的，所以绝对不是实现上的bug，就是规范故意这么定的~

备注：内容来源于stack exchange，提问作者Andy