input的required属性没反应，主要是因未用<form>包裹或提交按钮type不是submit；HTML5验证仅在原生submit事件中触发，且需注意浏览器兼容性与服务端二次校验。
input 的 required 属性为什么没反应？
常见现象是加了 required，但点击提交按钮时表单照样通过——大概率是因为你没用 <form> 包裹，或者用了 type="button" 而不是 type="submit"。HTML5 表单验证只在原生表单提交（submit 事件）中触发，不依赖 JS 就生效。
实操建议：
立即学习“前端免费学习笔记（深入）”；
-
<input required>必须放在<form>标签内，且提交动作由<button type="submit">或<input type="submit">触发 - 如果用 JS 拦截了
submit事件但没调用event.preventDefault()，验证仍会执行；但若调用了却忘了手动检查form.checkValidity()，就等于绕过了验证 - Chrome 和 Firefox 对
required的视觉反馈（如红边框、焦点提示）略有差异，Safari 在某些旧版本中对自定义控件支持弱
邮箱和数字格式验证：用 type 还是 pattern？
type="email" 和 type="number" 是最轻量的语义化验证方式，但它们的校验逻辑非常宽松。比如 type="email" 只要求含一个 @ 和至少一个点号，a@b.c 都能过；type="number" 允许空值、负号、小数点，甚至允许粘贴非数字字符后不报错（直到提交才拦）。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 想严格控制格式，优先用
pattern+title，例如：<input type="text" pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$" title="请输入有效邮箱"> -
pattern只对type="text"、"search"、"tel"、"url"、"email"、"password"有效；对type="number"无效 - 正则中的
^和$必须显式写出，浏览器不会自动锚定；漏写会导致部分匹配也通过
自定义错误提示：覆盖浏览器默认弹窗的关键操作
浏览器默认的 title 提示或 reportValidity() 弹窗很难定制样式，而且中文文案常被截断。真正可控的方式是监听 invalid 事件 + 手动设置 setCustomValidity()。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 每次输入后都应重置自定义错误：
input.setCustomValidity('')，否则后续验证会被上次残留的错误卡住 - 在
input.addEventListener('invalid', ...)中调用event.preventDefault()可阻止默认弹窗，但必须配合setCustomValidity()否则表单永远无法提交 - 如果多个字段共用同一套规则（比如密码确认），要在两个字段上分别调用
setCustomValidity()，仅在一个上设无效
兼容性与降级：IE10+ 和移动端的现实约束
IE10 支持 required、type="email" 等基础属性，但不支持 pattern 和 validity.customError；iOS Safari 对 inputmode 和 autocomplete 的支持碎片化严重，部分机型会忽略 type="number" 的软键盘类型。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 不要依赖
:valid/:invalidCSS 伪类做核心交互，它们在 IE 和部分安卓 WebView 中不可靠 - 移动端表单务必测试真实机型，特别是微信内置浏览器（X5 内核）对
checkValidity()返回值有时缓存异常 - 服务端永远要二次校验——前端验证只是体验优化，不是安全边界
真正难的是让验证逻辑和 UI 反馈同步，尤其在动态增删字段、异步加载表单、多步骤表单里，setCustomValidity 容易漏清、checkValidity 容易误判。这些地方不写测试，上线后基本靠用户报错才发现。
