原生 required 和 pattern 不能真正配合，因浏览器校验顺序固定：空值时只触发 valueMissing 并提前报错，跳过 patternMismatch；需用 setCustomValidity 完全接管校验逻辑，并在 submit 前 preventDefault。
原生 required 和 pattern 不能真正“配合”——浏览器校验顺序固定，required 会拦截空值并提前报错，根本不会走到 pattern 校验逻辑。
为什么 required + pattern 一起用时 pattern 不生效
典型现象：输入 5 位数字（少于 pattern="[0-9]{6}" 要求），浏览器只提示“请填写此字段”，不提示“请输入6位数字”。这不是 bug，是 HTML 规范定义的校验顺序：valueMissing（空值）→ valueMissing 或 badInput → patternMismatch。只要值为空，后续规则一律跳过。
常见误操作包括：
- 仅移除
required但保留pattern：此时非空字符串仍会触发pattern，但空值不再报错，失去必填语义 - 动态增删
required属性：容易导致input.validity.valueMissing状态残留，checkValidity()返回异常 - 只调用
setCustomValidity()却忘记reportValidity()：UI 不显示错误提示，用户无感知
用 setCustomValidity 统一接管校验逻辑
核心思路：去掉所有原生校验属性（required、pattern、minlength），完全由 JS 控制校验时机和错误文案。
立即学习“前端免费学习笔记（深入）”；
关键实操点：
- 每次校验前，必须对每个 input 显式调用
input.setCustomValidity("")清空状态，否则上次错误会一直卡住 - 绑定
input事件做实时反馈，或在提交时统一调用form.checkValidity() - 触发 UI 提示必须用
input.reportValidity()（Chrome 53+/Firefox 53+/Edge 79+）；老版本 Edge/IE 需搭配setCustomValidity()+ 手动 focus +reportValidity() - 正则校验建议用
^...$包裹，避免部分匹配（如/[0-9]{6}/会匹配 "1234567" 中的前六位）
示例逻辑：
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
const input = document.getElementById('code');
input.addEventListener('input', () => {
if (!input.value.trim()) {
input.setCustomValidity('此项为必填');
} else if (!/^[0-9]{6}$/.test(input.value)) {
input.setCustomValidity('请输入6位数字');
} else {
input.setCustomValidity(''); // 必须写！
}
});
form.submit() 前必须 preventDefault 并手动校验
如果表单有 novalidate 或已移除原生属性，直接 submit() 会绕过 JS 校验逻辑，直接发请求。
正确做法：
- 表单加
novalidate属性，禁用默认行为 - 监听
submit事件，第一行写e.preventDefault() - 先清空所有字段的自定义错误：
input.setCustomValidity('') - 再逐个校验或调用
form.checkValidity() - 校验失败时，调用
form.reportValidity()触发各字段 UI 提示
漏掉 preventDefault() 是最常被忽略的环节——表面看 JS 逻辑都写了，但表单仍静默提交。
服务端必须重复校验，且不能信任前端 validity 状态
前端 validity 对象（如 input.validity.valid）只是浏览器 UI 层的状态快照，可被绕过或伪造。例如用户禁用 JS、手动修改 DOM、或用 curl/postman 直接发请求。
所以：
- 后端必须独立实现完整校验逻辑（非简单复刻前端正则）
- 必填判断不能只看字段是否为空字符串，要考虑空白符、零宽字符、特殊编码等边界情况
- 正则校验需注意 PCRE/JavaScript 引擎差异（如 Unicode 字符类支持程度）
- 若前端用了
type="email"，后端仍要按 RFC 5322 严格校验，不能只依赖浏览器提示
真正安全的必填+规则组合，永远是「前端体验友好 + 后端兜底校验」，二者缺一不可。前端校验崩了，后端不能跟着一起失效。
