input[type="url"]不可靠，仅做基础WHATWG解析且静默截断空格，不校验协议真实性、域名可达性或路径合法性；必须用trim()后new URL()主动捕获异常并扩展业务校验。
input[type="url"] 不能完成可靠的网址校验，它只做最基础的 WHATWG URL 解析尝试，连空格都静默截断，更不检查协议是否真实、域名能否解析、路径是否合法。
为什么 input[type="url"] 会放行明显错误的输入
浏览器对它的处理，本质就是调用一次 new URL(value) 并忽略异常——但这个过程不可控、不反馈、不暴露细节。常见失效现象包括：
-
example.com（缺协议）在部分浏览器中直接通过，因为new URL("example.com")报错，但表单提交时某些浏览器会悄悄降级或忽略 -
https:///a.com（多一个斜杠）可能通过，而http:/a.com（少一个斜杠）失败，行为不一致 - 用户从微信粘贴的
" https://a.com "带首尾空格，input[type="url"]静默截断后值变成"https://a.com"，既不触发:invalid伪类，也不报错 - iOS Safari 和旧版 Android WebView 可能完全忽略该类型，软键盘仍是普通文本键盘
必须用 new URL() + trim() 主动捕获异常
真正可控、可反馈、可扩展的校验，只能靠 JS 主动调用 new URL()，且必须先 trim()：
- 不
trim()就调用new URL(" https://a.com ")→ 直接抛TypeError，不是格式问题而是字符串非法 -
new URL()能正确解析localhost:3000、https://例.com/测试（自动处理 IDN）、ftp://files，比手写正则稳得多 - 校验成功后可立刻读取
.protocol、.hostname、.pathname做业务约束，比如强制url.protocol === 'https:'或url.hostname.endsWith('.mycompany.com') - 相对路径（如
/api、./page）会失败——如果业务需要支持，就别用type="url"，改用type="text"并自行判断
URL.canParse() 是轻量替代，但兼容性有限制
URL.canParse() 返回布尔值、不抛错、不创建实例，适合做快速前置过滤，但它不是万能解：
立即学习“前端免费学习笔记（深入）”；
- 仅 Chrome 94+、Edge 94+、Firefox 117+、Safari 16.4+ 支持；Safari 15.x、Firefox
-
URL.canParse("javascript:alert(1)")返回true（因为javascript:是合法 scheme），但业务中通常要拦截 -
URL.canParse("/path", "https://a.com")可解析相对路径，但你仍得传 base，且它不校验 base 本身是否合法 - 不能替代
new URL()的属性访问能力，比如无法拿到.hostname做白名单判断
真正容易被忽略的一点：所有前端校验都只是守门员，new URL() 再稳，也拦不住禁用 JS 或直接 curl 发请求的调用。后端必须独立执行校验，且同样要 trim() 后再用 filter_var($url, FILTER_VALIDATE_URL)（PHP）、urllib.parse.urlparse()（Python）或 new URL()（JS 后端）——否则带空格的字符串一过来就崩。
