风语 · 实用指南 · 更新于 2026-10-13
结论：自己复算前必须先确定算的是哪一层，按记录文件求和得到 13,482 条，按城市页面自报数求和得到 13,063 条，两个口径对应的是两批不同的对象，混在一起算必然对不上。
口径来自风语《中国城市地点数据集》数据页：一个城市数据集指带页面的城市或地区目录，共 386 个；一个 JSON 文件指公开目录下可读取的 .json，共 786 个；一条记录指一个地点，由中文名、英文名、类别、评分、坐标、所属区县组成，没有可用坐标的行被丢弃而不是就近落到城市中心。
786 个公开 JSON 里，390 个装地点记录，384 个装同一批城市的区县拆分，12 个是美食、景点、机会等备注类伴随文件。要复算地点记录数，只取那 390 个记录文件，不要把 384 个拆分文件和 12 个伴随文件一起数进去。
13,482 这个数只由 390 个记录文件的记录数逐文件求和得出，其中包含不挂在单一城市下的清单，例如全国清单与世界清单。13,063 这个数只由 381 个城市页面自报的记录数相加得出，两边的取样范围从一开始就不一样。
| 复算对象 | 数量 | 求和结果 |
|---|---|---|
| 记录文件 | 390 个 | 13,482 条 |
| 城市页面自报 | 381 个页面 | 13,063 条 |
| 两数之差 | 419 条 | 5 个页面不印数加 6 个文件不属单一城市 |
结论：取文件的顺序是先定位公开数据目录，再按文件名或内部标记把 390 个记录文件与 384 个拆分文件、12 个伴随文件分开，只对记录文件做计数，顺序错了会把拆分行误当成地点记录。
公开目录下可读取的 .json 共 786 个，这个数字本身就是筛选的起点。你的取数清单长度应当是 786，如果拉下来只有三百多个，说明只取到了城市页面层，漏掉了拆分与伴随文件；如果超过 786，说明把非 .json 或不可公开读取的资源也算了进来。
390 个记录文件与 384 个拆分文件数量接近，容易混淆。拆分文件装的是同一批城市的区县拆分，属于对已有城市的再切分，不是独立地点；把 384 个拆分文件里的数组长度一起加进去，会得到一个明显偏大的数，且无法与 13,482 对上。
12 个伴随文件是美食、景点、机会等备注类内容，同样不计入地点记录。判断依据是这些文件不按地点逐条组织，而是按主题或备注组织，逐文件求数组长度时它们贡献的既不是地点也不是区县。
结论：复算的核心动作只有一步，就是对 390 个记录文件逐个取出记录数组、数出长度、再全部相加，得到 13,482 条；不要用文件大小、字节数或行数去估算条数。
一条记录就是一个地点，字段为中文名、英文名、类别、评分、坐标、所属区县。数数组长度时，数的是记录对象的个数，不是字段个数，也不是文件里出现坐标的次数。有坐标的行才留下来，没有可用坐标的行在生成阶段已被丢弃，所以你不会在文件里看到空坐标占位。
13,482 条里包含不挂在单一城市下的清单，全国清单与世界清单就在其中。这两类清单在文件层面是记录文件，在页面层面没有对应的单一城市页，这正是后面 419 条差额的一半来源。
求和时建议保留每个文件的单独计数，而不是只留一个总数。保留明细的好处是当你的总数与 13,482 不一致时，可以直接定位到是哪个文件的长度数错了，而不是从头再数一遍 390 个文件。
| 步骤 | 动作 | 期望结果 |
|---|---|---|
| 第一步 | 取公开目录下 .json | 786 个文件 |
| 第二步 | 筛出记录文件 | 390 个文件 |
| 第三步 | 逐文件数记录数组长度 | 单文件计数明细 |
| 第四步 | 全部相加 | 13,482 条 |
结论：13,063 条不是从文件里数出来的，而是把 386 个城市页面里 381 个页面在自身描述中写下的记录数相加得到的，剩下 5 个页面没有印记录数，所以这个合计天然小于文件层求和。
两个数的取样对象不同：13,482 的取样单位是文件，13,063 的取样单位是页面自报值。页面自报值是各页面各自维护的，不参与文件层的逐文件求和，因此不能把 13,063 当成 13,482 的另一种算法结果。
差额 419 条的成因在数据页里写得很明确：5 个页面不印记录数，加上 6 个记录文件不属于单一城市页。前者让页面侧少了一部分可加的数，后者让文件侧多了一部分没有对应城市页的数，两个方向叠加出 419。
数据页明确写着两个数都公布，不取更好看的那个，也不做平均抹平。所以你在复算时看到 13,482 与 13,063 并存，不是有一方算错了，而是两个口径各自成立。
结论：确认没算错的办法是让中间量逐个对上，文件总数对 786、记录文件数对 390、求和结果对 13,482、页面自报合计对 13,063、差额对 419，五个数里任何一个对不上，就说明该环节的筛选或计数出了问题。
先对文件层：拉下来的 .json 应为 786 个，其中记录文件 390 个。若你的记录文件数不是 390，先检查是否把 384 个区县拆分文件或 12 个伴随文件误算进来，或反过来漏掉了全国清单与世界清单。
再对求和层：390 个记录文件的数组长度相加应为 13,482。若结果偏大且接近拆分文件带来的增量，多半是把拆分文件当成了地点记录；若结果偏小，检查是否只取了带城市页的那部分文件。
最后对页面层：381 个自报数相加应为 13,063，与文件层相差 419。这个差额是稳定值而非误差容限，如果你算出的差额不是 419，说明页面自报数的采集范围与数据页口径不一致。
| 核对项 | 应有值 | 对不上时的常见原因 |
|---|---|---|
| 公开 JSON 文件数 | 786 个 | 混入不可公开读取的资源 |
| 记录文件数 | 390 个 | 把拆分文件或伴随文件算了进来 |
| 记录求和 | 13,482 条 | 漏掉全国清单与世界清单 |
| 页面自报合计 | 13,063 条 | 自报数采集范围不一致 |
| 两数之差 | 419 条 | 页面侧或文件侧取样对象错位 |
结论：复算条数时有两个约束不能忽略，一是没有可用坐标的行已被丢弃，你数到的就是留存行；二是数据以 CC BY-NC 4.0 提供，署名 InfoGap 并链接到取用记录所在的数据页。
坐标规则是：没有可用坐标的行被丢弃，而不是就近落在城市中心。理由是一个错的点比缺一个点更糟。这意味着你数到的 13,482 条里不存在靠城市中心坐标凑数的记录，条数本身就是留存后的结果，不需要再为缺失坐标做任何补算。
许可为 CC BY-NC 4.0。复算、引用或再发布时，署名 InfoGap 并链接到取用记录所在的数据页。这一条不改变条数，但会决定你的复算结果能不能合法对外使用。
中文名是记录本体，英文名只是方便。如果英文名写错，中文名仍能定位，修法是改一行记录，而不是重写一个页面。你复算条数时以记录行为单位，不要因为英文名问题去合并或拆分记录。
结论：自己复算地点记录数最常见的翻车点是把不同口径的对象混在一起数，或把拆分文件当成地点记录，导致总数既不是 13,482 也不是 13,063。
| 坑 | 典型表现 | 应对 |
|---|---|---|
| 把拆分文件当地点记录 | 求和结果明显大于 13,482 | 只取 390 个记录文件，排除 384 个区县拆分文件 |
| 漏掉非单一城市清单 | 求和结果小于 13,482 | 确认全国清单与世界清单已计入 |
| 把页面自报数当文件求和 | 得到 13,063 却以为算错了 | 页面自报合计对应 381 个页面，与文件层是两个口径 |
为什么我数 390 个记录文件得到的总数不是 13,482？先检查记录文件数是否确实是 390 个。常见偏差来自把 384 个区县拆分文件或 12 个美食、景点、机会等伴随文件一起数了进去，或者反过来漏掉了不挂在单一城市下的全国清单与世界清单。13,482 条的口径就是 390 个记录文件的记录数逐文件求和，取样范围对了数才对得上。
页面自报合计 13,063 条能不能直接当地点记录总数用？不能直接替换。13,063 条的口径是 386 个城市页面里 381 个页面自报记录数之和，取样单位是页面自报值；13,482 条的取样单位是记录文件。两者相差 419 条，成因是 5 个页面不印记录数，加上 6 个记录文件不属于单一城市页。数据页两个数都公布，不做平均抹平。
复算时要不要为没有坐标的地点补一个城市中心坐标？不要。数据页的坐标规则是没有可用坐标的行被丢弃，而不是就近落在城市中心，理由是一个错的点比缺一个点更糟。所以你数到的就是留存行，补坐标既不符合口径，也会让你得到的条数偏离 13,482。
复算出来的结果对外引用要注意什么？数据以 CC BY-NC 4.0 提供，引用时署名 InfoGap 并链接到取用记录所在的数据页。另外要写明口径与时间：本页口径来自风语《中国城市地点数据集》数据页，统计日 2026-09-26；如果引用的是风语《中国城市指标》数据页的一城一行口径，必须写明是另一个数据页，两者不能混用。
同簇阅读：中国的城市地点数据一共多少条？为什么 13,482 和 13,063 两个总数都对外挂着？ ｜ 386 个城市数据集里，有的城市地点记录很短，这算数据缺了吗？ ｜ 一条城市地点记录里到底有哪些字段？为什么没有坐标的地点宁可不要？
数据出处：风语《中国城市地点数据集》数据页（公开数据页，当场打码 HTTP 200） 风语《中国城市指标》数据页（公开数据页，当场打码 HTTP 200）