C#校验身份证号必须严格按GB11643-1999执行三步：先Trim().ToUpper()清洗，再正则初筛，最后用固定权重数组{7,9,10,5,8,4,2,1,6,3,7,9,10,5,8,4,2}加权求和模11，查表"10X98765432"比对校验码。
直接说结论：C#校验身份证号不能只靠正则，必须做三件事——格式清洗、地区码查表、前17位加权求和模11比对校验码。漏掉任何一环，生产环境必翻车。
为什么Regex.IsMatch(id, @"^\d{17}[\dX]$")总过不了真实数据
正则只能拦住明显畸形的输入，但拦不住“脏数据”：末位小写x、全角数字（如来自网页复制的“１”）、不可见Unicode空格、中文括号包裹、前后有制表符。这些都会让后续加权计算崩在int.Parse或char - '0'上。
- 必须先调用
idCard.Trim().ToUpper()统一首尾空白和大小写 - 再用
Regex.IsMatch(idCard, @"^\d{17}[\dX]$")初筛——注意这里X是大写，且正则不接受x - 接着逐字符用
char.IsDigit(c) || c == 'X'确认前17位全是数字、第18位仅限'0'-'9'或'X' - 别用
long.TryParse验前17位——它会把" 123..."也当合法，而国标要求严格连续数字
GetCheckCode(string id17)里权重数组和模运算怎么配才不出错
权重和模查表是硬编码，错一个数就全错。国标GB11643-1999规定死：new int[] { 7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2 }，模数固定11，余数映射表固定"10X98765432"（索引0→'1'，1→'0'，2→'X'…10→'2'）。
- 用
Enumerable.Range(0, 17).Sum(i => (id17[i] - '0') * weights[i]) % 11比手写for循环更稳，避免索引越界 - 余数结果是0~10，直接当索引去查
"10X98765432"[y]，别加1、减1、取绝对值 - 如果
id17含非数字字符，这一步会抛ArgumentOutOfRangeException——所以清洗必须在调用前完成，不是“最好做”，是“不做就崩”
为什么测试用例"11010119900307299X"返回false
表面看完全符合格式，实际常卡在三个隐蔽点：
- 末位是小写
x，不是大写X——ToUpper()没调或调得晚 - 字符串末尾有零宽空格（U+200B）或软连字符（U+00AD），肉眼不可见，但
Length还是18，Substring(17,1)取出来不是"X"而是"X\u200b" - 前17位中混入全角数字，比如“０”（U+FF10），
'０' - '0'≠ 0，导致加权和错误 - 生产建议：校验失败时打日志，输出
sum % 11、查表得到的期望字符、实际末位的(int)id[17]，一眼定位是算法错还是输入脏
真正难的从来不是写出GetCheckCode，而是把用户随手粘贴、OCR识别、旧系统导出的“身份证号”驯服成国标要求的干净字符串——现实数据永远比文档脏十倍。
