input[type="url"]不可靠，仅做最基础WHATWG解析，需trim()后用new URL()校验；它放行https:///example.com却可能因空格失败，不验证协议真实性、域名可达性或路径合规性，且浏览器行为不一致。
别指望 input[type="url"] 能真正把关——它只做最基础的 WHATWG 解析尝试，填 https:///example.com 或 ftp://files 都能过，但 github.com 或 http://a.com （首尾空格）却可能静默失败或直接报错。
为什么 input[type="url"] 不能当校验主力
浏览器内部只是调用了一次 new URL() 并捕获异常，但这个过程不可控、不透明，且行为不一致：
- Chrome 和 Firefox 对
https://localhost:3000放行，Safari 16.4 之前会拒绝 - iOS Safari 对
github.com这类无协议输入更宽松，Android Chrome 却严格拦截 - 用户从微信粘贴的链接常带首尾空格或零宽字符，
input[type="url"]会静默截断，既不触发:invalid也不抛错 - 它完全不管协议是否真实（
foo://bar）、域名能否解析、路径是否合规，甚至不处理相对路径
用 new URL() 手动校验才靠谱
必须先 trim()，再丢进 new URL()，否则空格直接导致 TypeError：
function isValidUrl(s) {
try {
new URL(s.trim());
return true;
} catch (_) {
return false;
}
}
- 它只接受绝对 URL：
/api、./page会失败；业务需支持相对路径就得换type="text" - 成功后可读取
.protocol、.hostname做业务约束，比如强制url.protocol === 'https:' - 自动处理中文域名（
https://例.com→ Punycode），但传入字符串必须是未编码的原始 Unicode - 比手写正则稳得多——不会回溯爆炸，也不漏判
localhost:3000或带端口的地址
URL.canParse() 是轻量替代，但兼容性有限
Chrome 94+、Firefox 117+、Safari 16.4+ 支持，旧版 Safari、IE、Node.js 全都不认：
立即学习“前端免费学习笔记（深入）”；
- 调用简单：
URL.canParse("https://a.com")返回布尔值，不抛错、不创建实例 - 支持相对路径 + base：
URL.canParse("/path", "https://a.com")→true - 但
javascript:alert(1)、data:text/plain,hello也会返回true，业务中仍需白名单过滤协议 - 降级方案只能是
try { new URL(...) } catch，不能省
pattern 属性不是救星，反而容易翻车
pattern 是叠加校验，不是接管逻辑，浏览器会自动加 ^ 和 $，你再写就失效：
- 想锁死 HTTPS 开头，得写
pattern="https?://[^\s]+$"，末尾[^\s]+防http://a b绕过 - 别抄网上“匹配所有 URL”的超长正则——要么漏掉合法地址（如 IPv6、IDN），要么拒绝
file:///path - 它不处理空格，仍要配合 JS 的
trim()；iOS Safari 和旧 Android WebView 常忽略它 - 和
input[type="url"]并存时，错误提示时机混乱，调试困难
真正容易被忽略的是三件事：用户粘贴时的空格和不可见字符必须在 blur 或 submit 时主动 trim()；后端收到的 URL 必须独立 trim() 后再用 filter_var($url, FILTER_VALIDATE_URL) 或 new URL() 校验；中文域名在传输中是 Punycode，后端解码要用 idna.decode() 或等价标准库，不能靠前端“看起来对”。
