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