电话号码中为什么不加一位 checksum？经常接到有人输错号码打错的电话，哪怕只加 1bit 校验效果也能降低 50%概率

因为打错了的电话也能收钱

1 年都不一定能接到打错电话的

然后各种 OS 内置优化的一个宣传点是手机号码只需要记实际位数， 校验位自动输入

又一个，我比专业的人更专业 系列 。。。。

想必 OP 看过历史战争的美剧，有拍摄过接线生的工作场景（其他剧可能也有出现，但本人见识浅薄）
电话近代化才出现程控式的交换，而且调度规则也很简单，沿用至今，只匹配前缀，例如 13800138000 ，匹配到 138 转发去中国移动总公司网关，总公司将 0013 转到当地分公司的网关，分公司网关的数据库才是记录最终用户的信息。
OP 提到新号码才实施，问题是旧号码怎么拨通？用户量上来后再迭代也要兼容老用户的，而且这个电话号码还是 primary key ，类比开发的时候，迭代会将 primary key 改来改去？除非是重建互不兼容的标准，IPv4/IPv6 就是例子


加了 checksum 还是有打错电话的，是不是还要加多 1 位去校验前 1 位 checksum （滑稽

好想法。过去是能尽量短一点，就短一点。
现在就算多一位数字也没有太大问题。反正不会用脑子记了。

@fuzzsh 13800138000 例子是简单描述，生活中是先匹配第一位，确定是手机还是固话还是特服，在转发到对应的机构/通讯公司

现在：185-0123-4567
新号码: 185-0123-4-5678
假设中间 4 是校验码，也可以是其他位数。

4 = hash(185-0123--5678)
这个 hash 算法返回 0-9 ，最大程度减少号码浪费。
拨号时，任意一位输错，手机端都可以计算出来，提醒拨号的人。

只对新号码验证，旧号码保留原来的逻辑。

好问题，之前还真没考虑过这件事

@Pipecraft #48 而且这个机制，可以解决充话费时，输错号码的问题。
想起前几天一位 V 友( @shubuqi )的帖子。
https://v2ex.ih06.com/t/1123088

我觉得 l 这个 idea 很好。但是看完回复震惊了。这么一个简单且生活中到处都在用的玩意，竟然这么多人都理解不了。

@PeakFish #4 搜一下国际银行账号 IBAN ，人家是两位数字 checksum ，绑死在银行账号里的。

虽然人们不愿意承认，但打错电脑是一种需求。

@drymonfidelia #23 放在 133 186 这些局号里完全可行。局号的冗余空间非常大。

@Donaldo #27 可以 老的 11 位，新的 12 位，和新旧身份证 机制一样

因为你这需求是伪需求，凭什么要为了这极小众的需求进行增加位数？
最近十年，我接到打错的电话不到 10 次……
一般的人不小心输错手机号码的概率很小，除非这个人粗心大意或者年纪大不会用手机。
关键是手动输入手机号码拨打的场景少，大部分是通过通讯录或者通话记录拨打。

为什么不给你的名字也加一个校验位呢，这样不会写错名字了。

不知道楼里为什么这么多大聪明在嘲讽，纯粹就是一个历史遗留问题，现在多少地方的固定电话第一位都是 8 的，更不用说手机号的第一位 1 了，事实上第一位根本没用。如果把第一位改成校验位是不是会好很多？当然你要说手机号的第一位是 1 是代表是手机拨号，牵涉到拨号程序那就没啥好说的了，还是上面的话，历史遗留问题。包袱太大，以至于无法实行。

没必要，已经有校验了：您拨打的电话是空号

@PrinceofInj 我觉得 1 某种程度上算是个 magic number ，一看就知道是手机号。当然也可能是为了后续拓展到 2 留的……

是一个挺有意思的问题，也许可以要求 sum(nums[:10]) % k == nums[10] % k ，这样会使(k-1)/k 的号码被废弃
假设打错电话通常是按错一个数字，那 k=2 也够用了