type属性的原生校验仅为弱提示，不实时拦截输入、不处理粘贴/脚本赋值等场景，无法替代JavaScript手动校验（如setCustomValidity+正则）和后端二次验证。
type="email" 和 type="url" 的校验行为不等于表单提交拦截
浏览器对 type="email" 和 type="url" 的原生校验只在调用 checkValidity() 或触发表单提交时触发，不会实时阻止用户输入。例如用户输入 test@，字段依然可编辑，只有点击提交或手动调用校验才会报错。
常见错误是以为设了 type="email" 就能防住所有非法输入，结果后端仍收到格式错误数据。必须配合 required 属性和 submit 事件监听，或主动调用 reportValidity() 显示提示。
- 仅靠
type不会阻止键盘输入，也不会自动修复内容 -
type="email"允许输入多个 @（如a@b@c.com），部分浏览器认为合法 -
type="url"对协议要求宽松：Chrome 允许example.com（无https://）通过校验
type="number" 的边界与小数点陷阱
type="number" 看似严格，但实际行为受 locale 和输入法影响极大。中文输入法下按小数点可能输出全角字符 ．，导致 valueAsNumber 返回 NaN；用户粘贴文本（如 "12.34abc"）时，浏览器会静默截断为 "12.34"，但 valueAsNumber 仍为有效数字。
更关键的是：min/max 和 step 不会阻止输入，只影响校验结果。比如 step="1" 时输入 1.5，字段值仍是 "1.5"，但 checkValidity() 返回 false。
立即学习“前端免费学习笔记（深入）”；
- 不要依赖
input.value判断是否为数字——应优先用input.valueAsNumber，它对非法值返回NaN -
step="any"可绕过小数位数限制，但不解决输入法导致的全角符号问题 - 移动端软键盘类型由
type决定，但 iOS Safari 对step支持不一致，建议后端二次校验
自定义校验必须覆盖 type 属性的“假安全感”
很多开发者把 type="tel" 当作电话号码校验，其实它完全不校验格式，连是否含数字都不管；type="search" 仅影响外观和软键盘，无任何验证逻辑。这些类型只是提示浏览器“你大概想输什么”，不是安全网。
真正可控的校验路径只有一条：监听 input 或 blur 事件，结合 setCustomValidity() 手动控制状态。例如手机号需 11 位纯数字，不能只靠 type="tel"，而要：
input.addEventListener('blur', () => {
const isValid = /^\d{11}$/.test(input.value);
input.setCustomValidity(isValid ? '' : '请输入11位手机号');
});
-
setCustomValidity('')是重置校验状态的必要操作，漏掉会导致后续校验永远失败 - 正则匹配前建议先
.trim()，避免空格干扰 - 不要在
input事件中频繁调用setCustomValidity()，否则会打断用户输入节奏
兼容性差的 type 值别拿来当校验主力
type="date"、type="time"、type="color" 在 Safari 和旧版 Android 上表现差异大。比如 iOS Safari 的 type="date" 不支持 min/max 动态更新，且用户可通过键盘输入任意字符串（如 "9999-99-99"），此时 valueAsDate 返回 null，但 value 仍是字符串。
这类控件的价值在于提升移动端体验（唤起原生选择器），而非替代校验逻辑。一旦需要精确控制格式或范围，就必须用 JS 补充判断，且不能假设 valueAsDate 总有值。
- 对
type="date"，始终检查input.valueAsDate instanceof Date，而不是只看input.value -
type="color"的值始终是 7 位小写十六进制（如"#ff0000"），但用户可手动修改为无效值，valueAsNumber不适用 - 所有依赖
type的校验都应在服务端重复执行，前端只是优化体验
type 属性提供的校验是弱提示，不是强约束。最易被忽略的点是：它不处理粘贴、拖放、脚本赋值等非键盘输入场景，也不统一跨浏览器的解析逻辑。真要可靠，就得自己动手做 setCustomValidity() + 正则 + 类型转换，别信浏览器的“自动”。 
