input type="url"仅做基础格式校验，要求必须含协议（如https://），不验证域名真实性或可访问性；需配合JS实时校验（如new URL()捕获异常）及后端白名单严格验证。
input type="url" 能用，但不能当最终校验手段——它只做最基础的格式检查，且浏览器行为不一致，后端必须重验。
为什么 input type="url 提交时还会过掉无效值
浏览器只在表单 submit 事件触发前做一次校验，且仅判断是否为「绝对 URL」：必须含协议（http://、https:// 等），不能是 /api 或 example.com。但它不发请求、不查 DNS、不验证可访问性。
- 用户禁用 JS 后可直接改 DOM：
el.type = "text"就绕过了 - 粘贴
https:// example.com（带空格）会被静默截断成https://，然后报错，但提示不明确 - Safari 对
ftp://、mailto:宽松，Chrome 可能直接拒收 - 空值、仅填
localhost:3000（无协议）也会被判定为无效
怎么补足 input type="url 的短板
保留语义和基础体验，用轻量 JS 做实时反馈，比全靠属性或全靠正则更稳。
- 监听
input事件，对value.trim()调用new URL(value)，捕获TypeError并标红输入框 - 避免手写正则匹配 URL——RFC 3986 太复杂，
new URL()是浏览器原生实现，更准也更省心 - 注意
new URL("https://")报错，但new URL("https:///")不报；业务若允许末尾无路径，可先.replace(/\/+$/, "") + "/"补斜杠再试 - IE 不支持
new URL()，如需兼容，得换validator.isURL()这类第三方库
后端为什么必须自己再验一遍
前端任何校验都不可信。URL 字符串可能含 XSS 载荷（如 javascript:alert(1)）、开放重定向（https://evil.com?redir=https://your-site.com），或协议未被业务允许（如 data:、vbscript:）。
立即学习“前端免费学习笔记（深入）”；
- Python 推荐用
urllib.parse.urlparse()检查scheme和netloc，拒绝空netloc或黑名单协议 - Node.js 可用
new URL(inputValue)捕获异常，再校验.protocol是否在白名单（['https:', 'http:']） - 绝对不要直接拼接用户输入的 URL 到
redirect或iframe src，必须规范化后再白名单比对 - 输出到 HTML 时记得做
html escape，否则<script>仍可能执行
真正麻烦的不是写对一个 input type="url"，而是想清楚：这个 URL 会用在哪？谁控制它的来源？有没有重定向、跳转、嵌入等高风险操作？这些地方漏掉一层校验，就可能变成突破口。
