银行卡号生成器
测支付表单、输入格式化、Luhn 校验这些逻辑时，需要卡号。这里按各卡组织的号段规则生成，校验位算准，不涉及任何真实账户。
生成的卡号仅供开发和测试使用。它们是按公开号段规则拼出来的随机数字，不代表任何真实银行账户，也不能用于支付、绑卡或任何与资金有关的操作。卡号在浏览器本机生成，不会上传到服务器。
银联 UnionPay：62 开头，常见长度 16、17、18、19 位，安全码 3 位。62 是银联主号段，国内卡绝大多数都是它；16 位最常见，借记卡也有 19 位
各卡组织的号段与长度
| 卡组织 | 主号段 | 常见长度 | 安全码 |
|---|---|---|---|
| 银联 UnionPay | 62 开头 | 16、17、18、19 | 3 位 |
| Visa | 4 开头 | 13、16、19 | 3 位 |
| 万事达 Mastercard | 51–55、2221–2720 | 16 | 3 位 |
| 美国运通 American Express | 34、37 开头 | 15 | 4 位 |
公开测试卡号
支付服务商的文档里都提供了固定的测试卡号，走沙箱环境联调时优先用它们，因为不同号段会触发不同的返回结果（成功、拒付、要求 3D Secure 等）。
复制按钮只复制数字。这些卡号在沙箱里有效，在真实支付网关上一律会被拒绝，所以不用担心误用。
卡号里的数字不是随便排的
银行卡号遵循 ISO/IEC 7812。最前面是发卡行识别码 IIN（大家习惯叫 BIN），前六位基本能看出卡组织和发卡机构，比如 62 开头是银联、4 开头是 Visa、34/37 是美国运通。中间是发卡行自己的账户编号，最后一位是根据前面所有数字算出来的校验位，用的是 Luhn 算法（也叫模 10 算法）。
Luhn 的算法很简单：从右往左数，偶数位（从右数第 2、4、6…位）的数字乘以 2，乘完如果超过 9 就把两个数字相加（等价于减 9）；把这些结果和剩下的数字加起来，总和能被 10 整除就通过。它的能力有限——只能挡住单字符输错和大多数相邻换位错误，挡不住有心构造的假号，所以校验通过绝不等于卡号真实存在。本工具生成的每一位都按这个规则算，因此能用真实的支付表单做前端校验测试。
各卡组织的长度规则也不一样，写校验逻辑时别写死 16 位。Visa 有 13、16、19 位（13 位是老卡，现在基本见不到）；银联 62 号段常见 16 位，借记卡也有 17、18、19 位；万事达 51–55 和 2221–2720 两个号段都是 16 位，其中 2221–2720 是 2016 年才启用的新号段，许多老代码的号段判断只写了 51–55，遇到新卡就识别成「未知卡种」，这是个很常见的坑。
美国运通比较特别：固定 15 位，安全码是 4 位（叫 CID，印在卡正面卡号上方），而 Visa、万事达、银联都是 3 位 CVV（印在签名条上）。做输入框时如果统一按 3 位处理，运通卡就会漏输一位。格式化显示也各有习惯：多数卡按 4 位一组分隔，运通是 4-6-5 的分组方式，部分前端库里就针对这一点单独做了分支。
写测试数据还有个容易忽略的细节：用同一张卡号反复跑测试用例，容易被风控当作异常行为；而各支付平台的沙箱是互相隔离的，Stripe 的测试卡在别家沙箱里不一定有意义。所以联调时优先使用目标平台文档里给出的专用测试卡，本工具生成的号更适合测自己项目里的表单校验、格式化显示、脱敏展示这类纯前端逻辑。