HTML input 的 pattern 属性自动隐式锚定，无需且不应使用 ^ 和 $；它仅匹配整个字符串，不支持正则断言，也无法校验前导零等复杂逻辑，需配合 JavaScript 补充校验。
HTML input 的 pattern 属性不支持正则断言，别用 ^ 和 $
HTML 表单的 pattern 属性**自动隐式锚定**——它只匹配整个字符串，等价于在你写的正则两端加了 ^ 和 $。所以写 pattern="^[0-9]+$" 和 pattern="[0-9]+" 效果完全一样，但前者多余且易误导。
常见错误是照搬 JavaScript 正则习惯，硬塞首尾锚点，结果调试半天发现没报错也不生效——其实是正则本身写错了（比如漏了量词），不是锚点问题。
-
pattern="[0-9]+"：允许一个或多个数字，如"123"✅，""❌，"12a"❌ -
pattern="[0-9]*"：允许空字符串或任意数字组合，通常不推荐用于“纯数字”校验 -
pattern="[0-9]{1,10}"：限制长度 1–10 位，适合手机号、ID 等场景
要排除开头为 0 的数字？pattern 做不到，得靠 JS 补充
HTML 原生 pattern 无法表达「非零开头的正整数」这种逻辑。像 "0123" 这种字符串，用 [0-9]+ 会通过，但它不是合法的十进制整数表示（除非业务明确接受前导零）。
这时候必须用 JavaScript 配合 checkValidity() 或 reportValidity() 做二次校验：
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
const input = document.querySelector('input[name="number"]');
input.addEventListener('input', () => {
const val = input.value;
// 先过 pattern 基础校验，再排除前导零（除非就是 "0"）
if (val && !/^[0-9]+$/.test(val)) return;
if (/^0[0-9]+/.test(val)) {
input.setCustomValidity('不能以 0 开头');
} else {
input.setCustomValidity('');
}
});
注意：setCustomValidity('') 才代表校验通过；非空字符串才会触发浏览器默认提示。
数字字符串 ≠ 数值类型，type="number" 会自动过滤非数字字符但有副作用
很多人误以为 <input type="number"> 能替代正则校验。它确实会阻止用户输入字母，但带来几个坑：
- 允许粘贴含字母的字符串（如
"123abc"），此时value可能是空或截断后的部分 - 允许输入
"e"、"+"、"-"、小数点，甚至科学计数法符号，不满足「纯数字字符串」需求 - 移动端唤起的是数字键盘，但用户仍可切换到字母键盘手动输入
- 提交时若值非法，
valueAsNumber为NaN，但value可能仍是字符串（如"123e"）
结论：如果后端接口明确要求字符串类型（如 JSON 字段是 "12345" 而非 12345），且不允许前导零、空格、符号，就别依赖 type="number"，老实用 type="text" + pattern + JS 校验。
真正需要「纯数字」时，优先考虑业务语义而非技术手段
问自己三个问题：
- 这个字段是否可能为
"0"？如果是，[0-9]+没问题；但00或012是否合法？ - 是否要兼容国际化数字格式（如千分位逗号、全角数字）？HTML
pattern默认只匹配 ASCII0–9 - 服务端是否已做强校验？前端正则只是体验优化，不能替代后端验证
最常被忽略的一点：正则校验只管字符组成，不管数值范围。比如 "99999999999999999999" 是合法的 [0-9]+ 字符串，但在 JS 中可能精度丢失，后端也可能溢出。范围检查必须单独做。
