不能只用 pattern 校验银行卡号，因为 pattern 仅支持字符串匹配，无法执行 Luhn 算法验证数学有效性，且无法处理空格、分隔符及不同卡组织长度差异，易放行无效卡号。
HTML 表单里不能直接用正则校验银行卡号
HTML 的 pattern 属性只支持浏览器原生的 RegExp（即 JavaScript 风格正则），但银行卡号校验不能只靠正则——它需要 Luhn 算法验证，而 pattern 无法执行逻辑计算。强行用正则（比如 /^\d{16,19}$/）只能检查长度和数字，会放行大量无效卡号，比如 1111111111111111。
为什么不能只用 pattern 校验银行卡号
银行卡号不是纯格式问题，关键在数学有效性：
-
pattern只做字符串匹配，不运行 Luhn 校验逻辑 - 不同卡组织长度不同：Visa 是 13/16/19 位，Mastercard 是 16 位，银联是 16–19 位，正则很难兼顾且无业务意义
- 用户粘贴带空格或分隔符的卡号（如
1234 5678 9012 3456）时，pattern会直接失败，体验差 - 移动端软键盘可能触发数字键盘，但用户仍可能输错，仅靠前端正则拦不住
实际可用的校验组合方案
必须结合 HTML + JavaScript，且优先保证体验：
- HTML 层：用
inputmode="numeric"和autocomplete="cc-number"帮助输入，pattern仅作兜底（例如pattern="\d{13,19}"），不依赖它判有效 - JS 层：监听
input或blur，先清理格式（移除空格、短横线等），再调用 Luhn 函数校验 - 示例 Luhn 校验函数（轻量、无依赖）：
function isValidCardNumber(num) {
const cleaned = num.replace(/\D/g, '');
if (cleaned.length 19) return false;
let sum = 0;
let isEven = false;
for (let i = cleaned.length - 1; i >= 0; i--) {
let digit = parseInt(cleaned.charAt(i));
if (isEven) {
digit *= 2;
if (digit > 9) digit -= 9;
}
sum += digit;
isEven = !isEven;
}
return sum % 10 === 0;
}
调用：isValidCardNumber("4532 0151 1283 0366") → true（注意它自动忽略空格）
htmlppt.skill
下载
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
容易被忽略的细节
真正上线时这几个点常被跳过，导致线上出问题：
- 不要在
submit时才校验——用户填完就该给反馈，否则提交失败再提示太晚 - 清理输入时别用
.replace(/\s+/g, '')就完事，要兼容中文全角空格、不间断空格（\u00A0）、甚至 Tab，推荐.replace(/[^\d]/g, '') - 后端必须重复校验 Luhn，前端校验纯属用户体验优化，不可信任
- 测试时务必覆盖带分隔符、粘贴场景、长按删除、iOS 自动添加空格等真实操作流
银行卡号校验的核心从来不是“怎么写正则”，而是“怎么把 Luhn 计算自然地织进输入流程里”。正则在这里只是个辅助过滤器，别让它承担不该担的责任。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
