type="url"仅校验URL结构：必须含http://、https://或ftp://协议前缀，不验证域名真实性或连通性；输入github.com等无协议地址会触发typeMismatch错误。

type="url" 的校验行为到底是什么

type="url" 只做极轻量的结构校验：必须含协议（http://、https://、ftp://），不能以 //example.com 或 example.com 开头；空格、中文、全角字符会直接触发 ValidityState.typeMismatch。它不查 DNS，不发请求，也不管域名是否真实存在——填 https://a 都能过。

为什么用户总说 “填 github.com 就报错”

因为浏览器严格要求协议前缀。用户想输得快，你却用 type="url" 拦住所有没协议的输入。常见错误现象包括：

• 用户输入 github.com → 浏览器报 typeMismatch，表单卡住
• 用户输错协议，比如 htp://example.com（少一个 t）→ 同样被拦
• 移动端 iOS Safari 对协议校验更宽松，Chrome 却严格，导致体验不一致
• 字段加了 required 但被 display: none 隐藏 → 控制台报 An invalid form control with name='xxx' is not focusable

怎么配才既校验又不反人类

别只靠 type="url"。推荐组合策略：

Doc To HTML

使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。

下载

• HTML 层用 type="text" + pattern="https?://.*" + title="请输入以 http:// 或 https:// 开头的网址"，保留移动端 URL 键盘，又不强求协议
• JS 层在提交前自动补协议：url = url.startsWith('http') ? url : 'https://' + url，但要防重复：url = url.replace(/^https?:\/\//, '').replace(/^\/\//, '') 再拼
• 表单提交时手动调用 form.checkValidity()，避免 event.preventDefault() 后校验失效
• 服务端必须二次校验——前端任何正则或 type="url" 都可绕过，且无法防御恶意构造的 URL（如 javascript:alert(1)）

自定义错误提示容易踩的坑

setCustomValidity() 不是设一次就完事。常见误用：

立即学习“前端免费学习笔记（深入）”；

• 只在 oninvalid 里设错，却不监听 input 清空状态 → 用户输对了还一直红着
• 写成 input.setCustomValidity("错误") 后没跟 input.addEventListener('input', () => input.setCustomValidity(''))
• 把 required 和 CSS 显示/隐藏混用：字段条件性必填时，用 JS 动态 toggle required 属性，而不是仅靠 visibility: hidden
• 忽略 :user-invalid 伪类兼容性——Safari 支持，IE 完全不认，别拿它当主要样式依据

实际中最容易被忽略的是协议补全逻辑和后端校验的配合。前端补 https:// 是为了体验，但后端收到的必须是完整、解码后、白名单过滤过的 URL，否则 XSS 或 SSRF 风险就在那儿。