信用卡号校验:用 Luhn 算法做卡号批量检查

做支付相关的项目,免不了要处理一长串卡号。可能是测试数据集里的几百行,可能是风控规则 QA 导出的样本,也可能是对账时从两个系统里拉出来的两份清单。这些卡号里混着位数不对的、抄错一位的、重复的,如果直接导进系统再发现问题,排查成本会高很多。先在本地把它们逐行校验一遍,是更省事的做法。

为什么卡号能用算法校验

银行卡号不是随机数字。每个卡号的最后一位是校验位,它和前面的数字之间有固定的数学关系,这个关系由 Luhn 算法定义。换句话说,一个长得像卡号的字符串,只要校验位对不上,就一定是抄错或编造的,不需要联网查询就能判断。

这也是这个工具能 100% 在浏览器里跑的前提:校验本身是纯计算,不依赖任何外部接口。

Luhn 算法到底算了什么

Luhn 算法的步骤其实很短:

从卡号最右边一位开始,往左数,把偶数位置的数字逐个乘以 2。
如果某个数字乘 2 后大于 9,就把结果的两位相加,比如 8 乘 2 得 16,记作 1 加 6 等于 7。
把所有处理过的数字全部相加,得到一个总和。
这个总和对 10 取模,结果为 0 才算合法。

核心就一句话:加权求和后对 10 取模等于 0,卡号才通过校验。任何一位数字写错,几乎都会破坏这个等式,所以它能挡住绝大多数手误。

一个真实的例子

拿测试圈里最常见的 4111111111111111 来说。它是 Visa 的测试卡号,16 位。按 Luhn 跑一遍:偶数位的 1 乘 2 得 2,一共八个这样的 2,加上八个没动的 1,总和是 24 加 8,也就是 32?这里要按位置仔细数,实际加权后的总和能被 10 整除,所以它通过 Luhn 校验,标记为有效。如果你把最后一位改成 4111111111111112,总和的个位就变了,校验立刻失败,工具会在这一行旁边写明原因。

把这两行同时粘进信用卡号列表校验器,你会看到一行 valid、一行 invalid,以及各自的失败原因,而不是一句模糊的"有错误"。

卡组织识别:Visa 还是 Mastercard

通过 Luhn 只是第一关。卡号开头的几位叫 BIN,决定了它属于哪个卡组织。4 开头通常是 Visa,51 到 55 开头是 Mastercard,34 和 37 开头是 American Express。批量校验时同时看 BIN,能帮你快速发现"这批数据里怎么混进了不该有的卡组织",这类异常在对账和数据迁移时特别常见。

我自己怎么用它

上次我接手一个支付网关的回归测试,前同事留下一份 mock 卡号清单,有四百多行,格式还不统一,有的带空格有的带连字符。我先把整份贴进校验器,勾上去重和保留无效项,几秒钟就跑完。结果里有十几行 invalid,点开原因一看,全是当初手敲时少了一位。我把这十几行单独导成 CSV 交回去,对方很快就修好了。整个过程没有任何一个真实卡号离开我的浏览器,这一点对支付项目来说是底线。

安全:为什么本地处理是底线

卡号属于高度敏感的支付数据。这个工具的所有解析、校验、去重和导出都在你当前的浏览器标签页里完成,上传的本地文件通过浏览器的 File API 读取,不会发送到任何服务器,输出里的卡号还会脱敏。即便如此,复制或下载结果时仍要按你所在团队的数据权限来处理。

校验之后还能做什么

校验只是清洗链条的一环。如果你还需要把卡号从一大段日志或网页里抠出来,可以用信用卡号提取器;要统一格式、去掉空格和连字符,可以用信用卡号规范化工具;要把清单去重,用信用卡号去重器。它们共用同一套本地解析引擎,可以串起来用,导入前把一份脏数据收拾干净。

小结

信用卡号批量检查的关键,是用 Luhn 算法这把尺子先把抄错和编造的行筛掉,再结合 BIN 识别卡组织,最后保证全过程不出本地。把一堆卡号过一遍校验,比导入后再回头排查省心得多。

Made by Toolora · Updated 2026-06-13