HTML pattern仅支持基础格式校验，无法处理查重、有效性等业务逻辑；需配合JS实现异步验证与状态管理，且须注意trim、required、type属性及竞态控制。
HTML 中根本不能用正则“校验”订单编号
HTML 的 pattern 属性确实支持正则，但它只是表单原生校验的触发条件，**不执行逻辑判断、不处理业务规则、不兼容复杂校验（比如查重、时间戳有效性、校验和）**。所谓“通过 HTML 正则校验订单编号”，本质是借 pattern 做最基础的格式拦截，且仅在提交时或调用 checkValidity() 时生效。
常见错误现象：pattern="^ORD-\d{8}-[A-Z]{3}$" 写对了，但用户粘贴带空格的 "ORD-20240520-ABC " 仍能通过——因为 pattern 默认不自动 trim，也不处理输入事件。
- 必须搭配
oninput="this.value = this.value.trim();"或监听input事件手动清理 -
pattern正则不带^和$也会被浏览器自动锚定，但显式写出更可控 - 移动端软键盘可能不触发
change，依赖input更稳妥
订单编号正则怎么写才靠谱
别直接套“UUID 风格”或“时间戳+随机数”这种模糊描述。先明确你的订单号生成规则，再反推正则。例如：
若后端生成规则是 ORD-{8位日期}{6位毫秒}{3位序列}（如 ORD-20240520123456001），正则应为：^ORD-\d{14}\d{3}$；若含分隔符和字母，如 ORD-2024-05-20-ABC123，则用：^ORD-\d{4}-\d{2}-\d{2}-[A-Z]{3}\d{3}$。
立即学习“前端免费学习笔记（深入）”；
- 避免过度宽松：
.*或\w+等同于没校验 - 注意转义：连字符
-在字符组[...]外无需转义，但在组内（如[-A-Z]）要放最前或最后 - 中文订单号？HTML
pattern不支持u标志，无法可靠匹配 Unicode，得靠 JStest()+/\p{Script=Han}/u
为什么 submit 时校验经常“失效”
典型表现：填了非法订单号，点提交没提示，表单直接发出去了。原因通常是：
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 表单控件缺少
required属性——pattern不隐含必填，空值会跳过正则校验 - 用了
type="number"或type="email"等类型，浏览器优先执行内置校验，覆盖或干扰pattern - JS 中调用了
form.submit()绕过了原生校验（原生校验只响应用户点击submit按钮或回车） - CSS 隐藏了默认错误提示（
::-webkit-validation-bubble被重置，又没手写:invalid样式）
修复建议：始终加 required；用 type="text"；JS 提交前手动调用 form.checkValidity() 并阻止默认行为。
真正该交给 JS 的部分
格式只是门槛，订单号是否真实存在、是否重复、是否已作废，这些都必须由 JS 发起 API 请求验证。HTML pattern 完全无能为力。
示例关键逻辑：
input.addEventListener('blur', async () => {
if (!input.checkValidity()) return;
const res = await fetch(`/api/orders/validate?sn=${encodeURIComponent(input.value)}`);
const { valid } = await res.json();
if (!valid) {
input.setCustomValidity('订单号不存在或已失效');
} else {
input.setCustomValidity('');
}
input.reportValidity();
});
注意：setCustomValidity('') 必须显式调用才能清除上一次的错误状态；reportValidity() 才会触发 UI 提示。
容易被忽略的是异步验证的竞态问题：用户快速切换输入，多个请求返回顺序错乱，导致正确结果被错误结果覆盖。加个简单的 abort 控制或防抖更稳妥。
