直接用int64解析银行卡号会溢出或在32位环境失败，应全程字符串处理；luhn校验需从右往左、双数位×2后减9而非取模；须清洗半角空格和连字符，拒绝全角字符；必须校验长度和bin前缀，三步短路判断。
为什么直接用 int64 解析银行卡号会出错
银行卡号最长 19 位（如某些银联卡），而 int64 最大值是 9223372036854775807（19 位但开头只能是 1–9，且受限于具体数值），看似够用——但实际校验中，你根本不需要把它当数字用。一旦用 strconv.ParseInt 或 atoi 类函数解析，就可能触发溢出 panic（比如遇到 "9999999999999999999"），或在 32 位环境提前失败。Luhn 算法全程只依赖单个数字字符的 ASCII 值，字符串遍历更安全、更快。
- 永远别对银行卡号做数值解析，哪怕只是临时转
int - 用
byte直接减'0'拿数字值，例如b - '0'，比strconv.Atoi(string(b))快 5–10 倍且零分配 - 注意前导空格和连字符：先用
strings.TrimSpace，再用strings.ReplaceAll(s, "-", "")清洗，但别用正则——没这个必要
luhnCheck 函数里双数位乘 2 后的进位怎么处理才不慢
Luhn 的核心是：从右往左，偶数位（第 2、4、6… 位）数字 ×2，若结果 ≥10，则减 9（等价于各位相加，如 16→1+6=7，而 16−9=7）。很多人写成 if d*2 > 9 { sum += d*2 - 9 } else { sum += d*2 }，逻辑没错，但分支预测失败会影响现代 CPU 流水线。更稳的做法是用位运算消除分支：
double := d * 2 sum += double - 9*(double>9) // Go 中 bool 转 int 是合法的：true→1，false→0
- 避免
if分支，尤其在校验高频调用场景（如支付网关入参过滤） - 不要用
digit * 2 % 9替代：虽然数学等价，但%运算比减法贵，且对 0 不成立（0×2=0，0%9=0 ✅；但 9×2=18，18%9=0 ❌，应得 9） - 索引方向很重要：必须从右往左数位（即最后一位是第 1 位，奇数位不加倍），不是从左往右
如何让校验函数支持 Unicode 空格和全角数字
真实用户输入常含全角空格（' '，U+3000）、全角数字（如 '１'，U+FF11），标准 strings.TrimSpace 对它们无效。若不做处理，'１２３' 里的 '１' 减 '0' 会得到负值，直接破坏校验结果。
- 先用
unicode.IsSpace(r)和unicode.IsDigit(r)遍历 rune 判断，但性能差——银行卡号最多 19 字符，用for i := 0; i 遍历 <code>[]byte更快 - 对非 ASCII 数字，不建议硬解 Unicode 映射；更务实的是：遇到非
'0'..'9'字节就直接返回false，并提示“仅支持半角数字”——这是绝大多数支付接口的实际策略 - 若真需兼容，用
norm.NFD.String(s)拆分组合字符，再过滤，但会引入额外分配和依赖，通常得不偿失
为什么校验前必须检查长度范围而非只看 Luhn 结果
Luhn 算法本身不验证卡号长度或 BIN（银行识别号）前缀。一个 5 位随机串 "12345" 可能通过 Luhn 校验（比如 "4012888888881881" 是有效 Visa 号，但 "0000000000000000" 也能凑出校验位为 0）。所以生产环境必须叠加规则：
- 主流卡组织长度：Visa（13/16/19）、Mastercard（16）、AMEX（15）、Discover（16/19），可建 map[
string]map[int]bool 快速查 - 先取前 6 位做 BIN 查表（哪怕只查前 2 位也比没有强），例如
s[0:2] == "42"→ Visa，再约束长度为 16 - 空、全零、全相同数字（如
"1111111111111111"）应单独拦截——Luhn 无法识别这类明显无效号
真正极速的校验，是把长度检查、BIN 前缀匹配、Luhn 三步做成短路逻辑：长度不对直接 return false，别浪费 CPU 跑完整算法。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
