url构造函数最可靠，但search参数需注意：search返回编码态字符串，searchparams.get()自动解码；pathname末尾斜杠影响值，拼接子路径应使用new url('detail', url).pathname；searchparams不暴露原始编码，ie需降级。
URL 类能直接解析但不自动解码参数值
浏览器原生 URL 构造函数是目前最可靠、兼容性最好的解析方式，它会把输入字符串按标准 URL 规范拆成 protocol、host、port、pathname、search 等属性。但要注意：search 返回的是原始查询字符串（如 "?name=%E4%BD%A0%E5%A5%BD&id=123"），不会自动 decodeURIComponent，参数值仍是百分号编码状态。
常见错误是直接取 url.searchParams.get('name') 就以为拿到明文，其实它内部做了自动解码——这点容易被忽略，但恰恰是安全的：你用 get() 拿到的是已解码结果，而手动读 search 字符串则仍是编码态。
-
new URL('https://api.example.com:8080/v1/users?id=1&sort=desc')是合法的，即使端口不是默认值（https默认 443，http默认 80）也会保留port属性 - 如果 URL 不含显式端口（如
https://api.example.com/v1），port属性为空字符串''，不是'443'；需自行判断协议补默认值 - 传入相对路径（如
/path?x=1）会抛TypeError，必须提供基础 URL 或确保是绝对地址
提取 pathname 要注意末尾斜杠和空路径
pathname 属性返回以 / 开头的路径段，但它的行为受 URL 结尾影响：若 URL 以域名结尾（如 https://a.com），pathname 是 '/'；若带路径但末尾无斜杠（如 https://a.com/api），pathname 就是 '/api'；若路径为空且无 trailing slash（极少见），实际仍会归一化为 '/'。
这在做路由匹配或拼接子路径时容易出错。比如想在当前路径后加 detail，不能简单写 url.pathname + '/detail'，因为 url.pathname === '/' 会导致结果变成 '//detail'。
- 安全拼接方式：
new URL('detail', url).pathname—— 利用URL构造函数的相对解析能力 - 判断是否为根路径：
url.pathname === '/' || url.pathname === ''（后者理论上不应出现，但某些非标准输入可能触发） - 服务端返回的
Location响应头可能含相对路径，前端用new URL(headerValue, window.location)才能正确解析
searchParams 对象适合读写参数但不暴露原始编码
URLSearchParams 是 URL 实例的 searchParams 属性，它封装了查询参数的增删改查，底层自动处理编码/解码。调用 .get()、.getAll() 返回的都是已解码字符串；用 .set()、.append() 输入的字符串会被自动编码。
这意味着你无法通过它获取原始 URL 中的编码形式（比如区分 %20 和 +），也不建议依赖其输出做签名或透传——若需保持原始编码，只能手动解析 search 字符串并用正则或 split('&') 处理，但风险高、边界多。
-
url.searchParams.has('q')比url.search.includes('q=')更可靠，能避免子串误匹配（如qq=） - 批量设置参数用
new URLSearchParams(obj)构造器，对象 key/value 会自动编码，但 value 为null或undefined会被转成空字符串 - IE 不支持
URL和URLSearchParams，需用core-js或降级方案（如document.createElement('a')）
协议和端口组合决定实际请求目标
protocol 返回带冒号的字符串（如 'https:'），port 是字符串类型（哪怕数值是数字）。二者组合才能准确还原连接信息：例如 protocol === 'http:' && port === '' 表示使用默认端口 80；protocol === 'https:' && port === '8443' 表示显式指定了非标 HTTPS 端口。
这个组合直接影响 fetch 请求是否跨域、是否被浏览器拦截（如混合内容）、甚至服务端 TLS 终止位置。不要只看 host 就认为“域名一样就没问题”。
- 检查是否为 HTTPS 安全上下文：
url.protocol === 'https:'，注意末尾冒号不能省略 - 拼接完整 origin 时：
${url.protocol}//${url.host}，不要用hostname + port，因为host已包含端口（如'example.com:3000'） - 服务端重定向时，若
Location响应头中 protocol 与当前页不一致（如从 https 跳到 http），现代浏览器会阻止并报Mixed Content错误
真正难处理的是用户粘贴的脏 URL：缺协议、双斜杠、中文未编码、空格混入。别指望一次 new URL() 全搞定，先用正则或字符串预处理补协议、去首尾空格、替换空格为 %20，再尝试构造。否则失败不是解析逻辑问题，而是输入根本不符合 URL 标准。
