仅靠正则表达式校验身份证号或手机号明显不足：身份证需分字符、结构、数学三步校验，手机号需覆盖新增号段、处理输入干扰并结合号段库验证。
直接说结论：只用正则表达式校验 CheckIdCard 或 CheckMobile 是明显不够的，尤其对身份证——它能拦住明显乱输的字符串，但拦不住“格式对、内容错”的假号（比如地址码无效、出生日期不存在、校验码算错）。手机号相对简单，但也要注意运营商号段更新和虚拟号段干扰。
为什么不能只靠 ^1[3-9]\d{9}$ 判断手机号
这个正则确实能匹配绝大多数 11 位以 1 开头、第二位是 3–9 的号码，但它忽略几个现实问题：
- 运营商新增号段（如 19x、16x）未被覆盖，2026 年已启用
192、198等号段，旧正则会误判为非法 - 虚拟运营商号段（如 170/171/162/165/167）虽属合法，但部分业务系统需单独白名单控制
- 空格、短横线、括号等用户输入常见干扰（如
"138-1234-5678"），正则不预处理就会失败 - 无号段归属验证：
"13800000000"符合正则，但实际未分配，应结合号段库或运营商接口做二次确认（如调用工信部公开号段 API）
regexp.MustCompile(`^([1-9]\d{5})(19|20|21|22|23|24|25|26)\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])\d{3}[\dXx]$`) 的三个硬伤
这个看似严谨的身份证正则，实际在生产环境容易翻车：
- 月份和日期部分没做互斥校验：
"20231301"（13月）会被(0[1-9]|1[0-2])放过，但"20230230"（2月30日）也能通过正则，因为[12]\d匹配了"30"—— 必须交给time.Parse("20060102", dateStr)实际解析并捕获 error - 年份范围写死为
(19|20|21|22|23|24|25|26)，到 2027 年就失效；更合理的是允许1900–2026（当前年份+1），且需动态计算 - 地址码只校验首位非零（
[1-9]\d{5}），但像"999999"、"000000"这类明显无效码不会被筛掉——必须查行政区划代码表（建议缓存map[string]bool，键为前六位）
真正可用的身份证校验要分三步走
跳过正则“一招鲜”，按顺序执行才靠谱：
-
字符级初筛：用
utf8.RuneCountInString(id)确认是 18 个 Unicode 字符（不是字节！），再逐 rune 检查前 17 位是否全为'0'–'9'，第 18 位是否为'0'–'9'或'X'/'x' -
结构级验证：取前 6 位查本地缓存的行政区划码（如
validAreaCodes["110000"] == true）；取第 7–14 位用time.Parse("20060102", dateStr)解析，并检查年份是否在1900–2026之间（避免未来日期） -
数学级校验：对前 17 位数字转成 int 数组，乘以权重系数
[7,9,10,5,8,4,2,1,6,3,7,9,10,5,8,4,2]，求和后% 11，查映射表["1","0","X","9","8","7","6","5","4","3","2"]是否与第 18 位一致（注意大小写统一）
最易被忽略的点：身份证里的“X”必须大小写兼容，但校验码计算时一律转大写比对；还有，time.Parse 对 "20230229" 这种非闰年 2 月 29 日会直接返回 error，不必自己写闰年逻辑——依赖标准库即可。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
