input[type="url"]不可靠，仅按WHATWG标准粗略解析字符串，不校验协议真实性、域名可解析性或路径合规性；必须trim()后用new URL()手动校验，并在后端独立二次验证。
input[type="url"] 本身不校验协议合法性、域名可解析性或路径合规性，仅尝试按 WHATWG URL 标准解析字符串；靠它拦住非法网址是不可靠的，必须配合 trim() + new URL() 手动校验，后端还得独立再验一次。
为什么 input[type="url"] 总是“看起来能用，实际拦不住”
浏览器内部只检查是否含冒号+斜杠类结构，比如 foo://bar、https:///example.com、www.example 都可能通过。它不验证协议是否存在、域名是否合法、路径是否符合 RFC 3986，也不拒绝带中文路径但缺协议的原始字符串。本质是个轻量提示控件，不是校验器。
- 用户粘贴带首尾空格的链接（如从微信复制），
input[type="url"]会静默截断但不报错，导致new URL(" https://a.com ")直接抛TypeError - 相对路径（如
/api、./page）必然失败，业务若需支持就得换type="text" - iOS Safari 和旧版 Android WebView 对它的行为不一致，错误提示时机和文案都可能不同
用 new URL() 做 JS 校验比写正则更稳
现代浏览器中，new URL(s.trim()) 会真正尝试解析，格式非法就抛错，代码短、覆盖全、无回溯爆炸风险。它支持 localhost:3000、https://例.com、带端口和 IDN 域名的合法地址，比手写正则靠谱得多。
- 必须先
trim()，否则空格导致直接失败 - 校验后可进一步读取
.protocol、.hostname做业务约束，比如url.protocol === 'https:'或url.hostname.endsWith('.mycompany.com') - 它只校验绝对 URL；如果业务允许相对路径，就别用
new URL()，得换逻辑
pattern 属性不能替代 new URL()，且容易翻车
pattern 是叠加校验，不是接管逻辑。浏览器会自动给正则加上 ^ 和 $，你再写就失效；它也不处理空格，仍需 JS 配合 trim()。常见坑：
立即学习“前端免费学习笔记（深入）”；
- 想强制 http/https 开头，用
pattern="https?://[^\s]+"（末尾[^\s]+防止http://a b这类绕过） - 别抄网上“匹配所有 URL”的超长正则——兼容性差，还可能拒绝合法地址（如带端口、中文域名）
- iOS Safari 对
title提示支持弱，用户可能看不到错误文案，得额外 JS 补提示 -
pattern只在表单提交或调用checkValidity()时触发，不监听实时输入，没反馈就等于没校验
后端校验绝不可省，且必须独立执行
前端任何校验都可被绕过：禁用 JS、改 DOM、curl 直发请求，都能跳过所有前端逻辑。PHP 必须用 filter_var($url, FILTER_VALIDATE_URL)，Python 用 urllib.parse.urlparse()，JS 后端用 new URL() 再 throw。注意：
- 后端也得先
trim()，否则带空格字符串直接失败 -
FILTER_VALIDATE_URL遵循 RFC 3986，比前端更严格，支持 IPv6 和 IDN 域名 - 若只要 HTTP/HTTPS，还得用
parse_url()提取scheme并限定，否则file:///、git://都会返回false，需单独处理
最容易被忽略的一点：服务端收到的 URL 若含中文或空格，必须正确 decode —— 前端提交时 type="url" 不改变编码行为，空格变 +、中文变 %E4%BD%A0，和 type="text" 完全一样。
