上周末我在地铁上翻自己的出行记录时意识到一个问题在北京这座城市生活了这么久我到底去过多少个地铁站、换乘过多少条线路其实完全没有概念。手机相册里存得下风景微信里翻得到聊天记录但“我和这座城市之间的空间关系”没有任何工具能一笔笔画清楚。这才是我想做北京地铁足迹地图记录工具的真正原因。不是要给地铁爱好者的收藏夹再添一个花哨页面而是想回答一个很朴素的问题我每天走过的这张城市网到底覆盖了多大的范围。现在这个工具已经上线代码也开源了。这篇文章把它的设计思路、实现链路和踩过的坑写清楚给准备做类似地图工具、或者单纯想给自己的生活留一份轨迹数据的人一些参考。这里先给出我的核心判断一个足迹地图工具的价值不在于把地图画得有多好看而在于是否形成了“输入记录—路径补全—持久化—回溯”的数据闭环。如果只是画一条线、亮几个点那它和一张静态效果图没有区别。真正让足迹地图有意义的是它能持续使用、持续积累最终变成属于你自己的城市时间线。1. 先想清楚我们真正要记录的是什么1.1 地铁站是城市骨架的“锚点”要理解足迹地图为什么用地铁站做节点得先把城市地图的呈现方式想明白。城市很大但我们真实的活动半径其实是由少数几个锚点撑起来的家、公司、常去的商圈、朋友的小区、约会的电影院。这几个锚点之间交通线路就是连接线。地铁站恰好同时具备锚点和连接线两种属性。它是一个有名字、有坐标、有线路归属的空间节点。记录你坐过哪些站表面上是在记录交通轨迹实际上是在记录这座城市对你开放过多少区域。这也是为什么我不建议只用 GPS 画一条漂移轨迹。GPS 轨迹依赖信号抖动大、没有语义回看时很难知道那条曲线到底意味着什么。而地铁站是“有名字的地理坐标”一看到“天通苑”“西二旗”“国贸”这几个字不需要地图你脑海里就已经自动把城市地图展开了。1.2 足迹记录不只是打卡而是把碎片经历变成个人时间线最初做这个项目的时候很多朋友会问这和地铁站打卡 App 有什么区别打卡的本质是“当下验证”到过一站盖一个章是离散的收集行为。足迹记录的本质是“时间与空间的堆积”。记录下来的每一笔行程都包含了日期、起始站、终点站、换乘线路这些信息。当这些记录攒到一定量级它们就会变成一条个人时间线你住过哪个区域工作在哪个片区周末的活动半径从哪一年开始变大哪条新线开通之后你第一时间去坐了。这些信息不是通过回忆拼凑出来的是从数据里长出来的。所以我在设计记录字段时刻意保留了乘车日期和乘坐状态。这看起来只是两个普通字段但它们才是让足迹地图从“空间展示”升级为“时间回溯”的关键。1.3 一个判断足迹工具的价值不在画图在数据闭环做开发时我一直提醒自己不要被地图可视化牵着走。地图只是界面真正的核心是数据闭环。一个合格的足迹地图记录工具至少要满足三个环节输入环节要足够轻。记录一次行程不能要求用户逐站打勾否则新鲜感一过就弃用了。路径补全要可靠。用户只需要输入起点、终点和换乘线路系统要能自动把途径站点点亮。数据要能导出。记录的最终归属是用户自己。如果数据只存在应用里应用一旦关闭所有痕迹就消失了。这个判断直接决定了工具形态。它不能只是一个照着地图画线的静态页面必须是一个能记录、能保存、能恢复的小系统。开源版本的核心就是把这条数据闭环跑通。2. 核心链路拆解数据、记录与路径补全2.1 站点数据从哪来又要整成什么样北京地铁站点数据是项目的基础也是最耗费耐心的部分。常见的数据来源包括公开的线路图 JSON、地图平台的 GeoJSON 数据、百科站点列表以及地铁族爱好者整理的线路时刻表。但不管从哪个来源拿数据都需要统一整理成项目能识别的结构。这个工具里用的站点数据大概类似这样{ line: 1号线, stations: [ { id: bianmen, name: 苹果园站, lng: 116.178, lat: 39.926, transfers: [6号线] } ] }字段不需要太多但有几个点非常重要id必须是稳定的唯一标识不能直接用中文站名做 key。原因后面会讲。坐标建议统一使用 GCJ-02 国测局坐标避免和国内底图服务偏移。transfers数组要标注换乘线路这是路径补全的关键依赖。数据整理完成后最好人工抽样检查 50 到 100 个主要站点确认名称、坐标、换乘关系没有大问题。数据源没有一个能直接落到“开箱即用”大多数情况要经过清洗和去重。项目里保留的就是一份清洗后的静态 JSON 数据不会实时从在线地图拉取这样加载快也方便离线使用。2.2 一次乘车的记录模型输入起终点而不是逐站点击给用户提供“逐站点亮”的方式是最直觉的但也是最反人类的。一趟常规通勤可能要经过 10 个站换乘 2 次如果每坐一站都要打开手机标记一下坚持不了三天。更合理的记录模型是用户输入起始站、终点站、乘坐日期。系统自动补全把这条线路上的途径站点一次性点亮。如果行程涉及换乘则要补充换乘线路。例如从中关村到国贸系统自动判断需要乘坐 4 号线换 1 号线那两个线路上从起点到目的地的所有站都会被标记为“已乘坐”。这个模型才符合真实乘坐动作。用户记住的永远是自己从哪站上车、在哪个站下车、中间换了几条线而不是沿途一共经过了几个站。2.3 换乘路径补全从 A 到 B如何把中间站自动点亮路径补全是这个工具最核心的逻辑。编写时顺着一个简单思路做先把一条线路的站点按顺序排列再在换乘站把两条线拼接起来。以“4号线换1号线”为例找到 4 号线的站点顺序从“中关村站”到“西单站”之间经过的所有站全部标记为已乘坐。在换乘站“西单站”切换到 1 号线。找到 1 号线的站点顺序从“西单站”到“国贸站”之间的所有站全部标记为已乘坐。伪代码大概是这样的def mark_ride_path(start_station, end_station, lines): current_line lines[0] current_station start_station for line in lines: stations line_stations[line] idx_current find_index(stations, current_station) idx_end find_index(stations, end_station) if line lines[-1] else find_transfer_index(line, lines, lines.index(line) 1) # 标记该线路上从 idx_current 到 idx_end 之间的所有站 mark_stations(stations, idx_current, idx_end) current_station idx_end实际编码时要注意线路顺序可能正反不一致。有的数据源里 4 号线是从安河桥北往天宫院排列有的是反的。所以补全逻辑里必须做方向判断不要假设数据源里的站点顺序就是正向的。2.4 环线、分叉线和同名站点的处理北京地铁线网有几类特殊情况是所有类似工具都会遇到的环线10 号线、2 号线这种闭合线路。不能简单地按起点到终点截取要判断走内环还是外环或者干脆默认按短路径计算。分叉线一些站点发车方向不同会分叉。此时要结合用户的换乘方案来判断实际经过的站点而不是单纯按当前线路所有站点点亮。同名换乘站不同线路都有“西直门站”但如果站点 ID 不一致就会出现第二次坐 4 号线经过西直门时1 号线的西直门站没有被点亮。处理思路很简单站点归属以站点 ID 为准而不是以站名为准。换乘关系必须通过transfers字段显式关联同一座换乘站的多线路名在数据里要指向同一个 ID。遇到环线时我的建议是不追求绝对精确优先采用“短路径优先”策略。如果两个方向距离差不多默认按数据源中的方向顺序处理但在页面结果里把环线标识出来让用户能自行判断是否需要切换方向。3. 技术选型与可视化实现3.1 技术架构推荐纯前端优先后端看需求再加这个项目的技术架构如果只服务于个人记录我会优先推荐纯前端方案。原因很直接部署成本低可以直接扔到静态托管平台。个人数据存储在本地或自己的数据库不需要复杂的鉴权体系。站点数据本身就是静态 JSON不需要后端实时计算。一个可行的架构组合是层级选型原因前端框架Vue 或 React组件化方便管理底图、状态面板和记录表单地图渲染Leaflet / MapLibre GL / ECharts GL轻量支持自定义覆盖物不依赖商业 API Key底图瓦片高德、百度、Carto 等 2D 瓦片国内场景优先选用 GCJ-02 坐标的底图数据存储localStorage 或 SQLite个人使用足够导出 JSON 即可备份部署GitHub Pages / Gitee Pages / Nginx / Docker按是否带后端灵活选择如果后续想实现多设备同步、分享页面、游客查看足迹那再加一个轻后端即可通常一个 Node.js 或 Python 的服务就够了。做这类工具时最常见的错误是第一版就上复杂权限体系反而拖慢核心闭环。3.2 地图渲染的三层分离底图、线路、站点整个地图可视化可以拆成三层底图层负责展示真实地理环境保持视觉弱化不需要太强的 POI 展示。线路层把每条地铁路线的 Polyline 按主题色绘制出来。未乘坐线路用浅色绘底已乘坐线路在足迹回看模式下用主色高亮。站点层在地铁站点位置绘制圆点或图标。已乘坐使用高饱和度色未乘坐使用灰色。分层最重要的收益是渲染逻辑不会纠缠在一起。切换“足迹回看模式”时只需要改动线路层和站点层的数据源底图不动逻辑非常清晰。// 站点状态数据示例 const stationStatus { bianmen: { visited: true, lastVisit: 2024-11-02 }, gongzhufen: { visited: true, lastVisit: 2024-11-02 }, muxidi: { visited: false } };3.3 数据存储、导入导出与备份足迹记录数据建议按条结构化保存每一条记录至少包含乘坐日期起始站 ID终点站 ID换乘线路数组途经站点 ID 数组补全后生成保存到 localStorage 的好处是无需后端、刷新不丢。但 localStorage 有容量上限也不适合长期唯一性存储。所以我强烈建议在设置页提供 JSON 导出功能。导出文件结构大概像这样{ records: [ { date: 2024-11-02, from: zhongguancun, to: guomao, routes: [4号线, 1号线], stations: [haidianhuangzhuang, xisi, xidan] } ], version: 1.0 }记录文件的版本号字段很重要。以后一旦调整站点 ID 规则可以靠版本号做数据迁移。这算是一个通用经验给任何导出数据都留下version字段能救回很多次因为结构变更导致的“历史数据读不出来”事故。3.4 统计视图怎么加才不会过度设计第一版不需要做太多统计。我建议只保留三个维度已乘坐站点数直接展示整体覆盖进度。已乘坐线路数方便看出你集齐了哪条线。最近乘坐记录按日期倒序列出保持“日志感”。这三个统计的完成度已经足够回答“我在北京地铁里覆盖了多少空间”这个最初的问题。像站点覆盖排行、连续乘坐天数、最常换乘路线这类进阶统计应该等基础闭环稳定后再加。过早加统计视图会让页面变成控制台而不是一个让人愿意持续记录的工具。4. 从自用工具到开源项目我建议补齐的几块拼图4.1 开源前的自查清单个人工具做出来之后自己用得顺手不等于能直接开源。从个人项目变成开源项目最少要过一遍自查清单项目根目录是否有 README能说清楚项目是什么、怎么用、怎么部署。是否有 LICENSE 文件。如果没有法律上默认保留所有权利别人根本不能合法使用。是否已移除本地调试用的 API Key、私密 token、数据库密码。站点数据是否和代码分离。这样其他人换城市时不需要改动源码只需要替换数据文件。是否提供了最小可运行示例。别人 clone 下来能不能一条命令跑起来看效果。是否写了已知限制。比如“线路数据更新到某年某月”“环线方向默认按短路径计算”。开源并不意味着要写完善的项目管理文档但至少要让人在 10 分钟内能跑起来并理解项目结构。4.2 许可证选择和平台发布许可证的选择经常被新手忽略。常见选择有两个方向MIT 许可证允许别人商用、修改、再分发只需要保留版权声明。适合希望项目被广泛复用的工具。GPL 许可证要求衍生作品也必须以 GPL 协议开源。适合希望项目保持开源的分享者。如果你的项目主要价值在数据整理和设计思路可以用 MIT引导更多人基于你的代码去适配其他城市。如果希望项目生态始终保持开放可以选择 GPL。发布平台方面代码托管到 GitHub 和 Gitee 都是常见选择。国内用户通常更习惯从 Gitee 访问但国际关注度主要在 GitHub。不冲突可以两边同步发布只要在各平台仓库的 README 里标明原文仓库地址即可。4.3 部署方式静态页、Docker 与 Nginx如果项目是纯前端方案部署极其简单。构建后打包出一个dist/目录扔到任意静态托管或 Nginx 里就完成了。# 前端项目常见构建流程 npm install npm run build # 构建后输出 dist/ 目录配置 Nginx root 指向该目录即可如果带了轻后端则可以考虑 Docker 部署。一个极简的 Dockerfile 示例结构大概是FROM node:20-alpine WORKDIR /app COPY package*.json ./ RUN npm install --production COPY . . EXPOSE 3000 CMD [node, server.js]这里需要注意的是如果项目里的底图服务需要域名白名单在本地部署和线上部署时要提前把访问域名配置进底图服务的白名单否则页面能加载但地图瓦片会挂掉。4.4 开源项目的边界不做免费客服也要有反馈模板开源项目最容易被忽略的坑是作者被铺天盖地的 Issue 淹没。一个好的做法是在 Issue 模板里要求用户提供运行时信息浏览器版本、部署方式、站点数据版本、控制台报错截图。这样能大幅过滤掉无效反馈。也要在 README 里明确写出维护边界。比如“该项目只确保北京地铁数据下运行正常其他城市需自行替换数据文件”“不处理依赖外部数据服务的实时线路运营问题”。这不是逃避责任而是让开源项目保持健康维护节奏的必要手段。5. 开发过程中最容易踩的坑与排查思路5.1 数据坑站点名和坐标不一致北京地铁站点数据最大的坑不是数据量不够而是来源混乱。同一个站在不同来源里可能叫法不同、坐标不同、所属线路顺序不同。比如有些数据源使用旧版站名有些使用工程名有些坐标是 WGS-84有些是 GCJ-02叠到国内底图上一看站点偏移几十米到几百米。经验在项目开始阶段就建立一个“站点收编表”把不同来源的站点信息逐条对齐。只依赖单一数据源通常会留下大量隐性错误。具体排查路径先看单个站点的坐标是否落在底图上正确位置。再看换乘站是否在所有相关线路中都使用了同一个 ID。最后检查整条线路的站点顺序是否存在明显的绕路或跳站现象。这一步不能跳过因为后面的路径补全完全依赖数据正确性。数据一旦错了路径补全全崩。5.2 逻辑坑换乘站被重复点亮换乘站重复点亮是足迹地图的经典 Bug。例如西直门站在 2 号线、4 号线、13 号线中都会出现。如果你保存的乘坐记录只按线路处理就会在换乘时出现同一个站点点亮两次。而且两个记录并不是同一份数据后续统计站点数时会多算。解决方案是引入“站点访问状态表”访问状态以站点 ID 为键同一个 ID 只会被点亮一次。换乘站的线路归属只影响线条颜色不影响访问标记。这段逻辑看起来简单但很多人做的时候会忽略直到统计站点覆盖率时才发现总数不对。5.3 性能坑页面卡顿的排查顺序站点少时性能问题不明显但北京地铁站点总数超过几百个后如果直接给每个站点渲染一个 DOM marker页面就会明显卡顿。尤其是地图缩放旋转、轨迹回放时帧率会肉眼可见地下降。排查顺序建议这样做先看渲染节点数量当前地图范围内同时渲染了多少个 marker超过 300 个是否启用了聚合或 Canvas 绘制。再看数据源大小站点 GeoJSON 是否包含大量冗余字段网络加载耗时和解析耗时是多少。再看底图资源是否在弱网环境加载了高清遥感瓦片是否同时加载了多套底图。最后看交互代码地图缩放时是否执行了不必要的全量重绘比如每次 zoom 都重新生成所有站点图层。多数情况下把 DOM marker 换成 Canvas 或 SVG 图层卡顿问题就解决了大半。这个阶段的优化收益远大于去纠结框架选择。6. 适用边界、使用路径和后续规划6.1 适合谁用不适合谁用任何工具都有自己的边界。这个足迹地图最合适的使用者是经常坐地铁通勤、出差希望对城市空间有直观感知的人。对地铁线路和城市交通变迁感兴趣的人。准备按线路“刷站”、把自己住过的城市走透透的人。想做城市足迹类可视化项目参考数据结构和实现路径的开发者。不适合的使用场景包括需要精确统计每一趟班次时刻、票价和进出站时间的通勤分析。这需要接入交通卡或乘车码的明细数据手动输入模式的颗粒度达不到。需要边走路边实时记录户外轨迹。这是纯粹的 GPS 轨迹记录工具不是地铁站足迹工具。需要跨城市实时更新的运营数据。如果每个城市的线路都在不断增加可持续维护的压力会非常大开源协作是更可行的方式。判断标准只有一句话如果你的目标是通过站点数据回溯自己和城市的关系这个工具是合适的如果你需要的是一份精确的交通消费账单它不适合。6.2 首次使用的最短可行路径不建议第一天就疯狂录入历史行程。更建议按最短路径先让数据闭环跑起来第一步确认站点数据能正常加载地图上能看到完整线网和站点。 第二步连续一周记录上下班通勤每次只记起点、终点和换乘线路。 第三步导出一次 JSON 备份确认导出文件结构完整。这三步做完你才真正理解了工具的输入模型和数据回流方式。接下来再按自己的需求去补历史记录比如把刚来北京时住过的区域、以前常和朋友约饭的商圈一条一条补进去。每补一笔地图就会亮一批站点那种“原来我都去过这些地方”的体感是看任何 App 截图都不能替代的。6.3 从记录到探索这个项目还可以长成什么样现有版本解决的是“记录已经发生过的足迹”但更有趣的方向是“用足迹反过来推动探索”。后续比较适合的演进方向我从易到难排一下覆盖进度页展示总车站覆盖比例、已乘坐线路进度、还剩多少站没去过做成可分享的卡片。新线开通提醒在站点数据更新后第一时间识别新开通站点并在足迹图上高亮。多城市模板把数据整理方式沉淀成模板让其他城市的使用者替换数据文件即可复用。周末随机刷站模式随机推荐一个少去区域的地铁站鼓励使用者通过地铁探索城市新区。这里最有价值的是第 3 条。足迹地图的真正终点不应该是北京一个城市而应该成为每个人记录自己城市蔓延史的一套通用工具。北京只是第一个数据样本。回到最初的问题。走过这座城市这么多站点最终被点亮的地图不是给别人看的成绩单而是一张属于你自己的城市时间线。北京地铁在今天只是线网图上几百个点组成的网络但在足迹记录完成的那一刻它就有了温度哪一年你开始不再去那个站哪条新线开通后改变了你的通勤路径哪次跨城约饭让你第一次接通了原来不相邻的两片区域。工具本身并不复杂。复杂的是把一份静态地图变成一条持续累积的个人数据流。这也是开源这件事真正吸引我的地方——不需要每个人都从零开始整理数据、画底图、写路径算法只要一个人把轮子做好其他人就可以把更多城市、更多故事叠加上去。如果你也想做类似的东西我的建议只有一个先别想着把所有功能做完先跑通“记录一次行程点亮一路站点导出一次备份”的小闭环。剩下的优化、美化、统计都会在这个闭环稳定生长出来。
从数据闭环到开源：我的北京地铁足迹地图工具开发实践
上周末我在地铁上翻自己的出行记录时意识到一个问题在北京这座城市生活了这么久我到底去过多少个地铁站、换乘过多少条线路其实完全没有概念。手机相册里存得下风景微信里翻得到聊天记录但“我和这座城市之间的空间关系”没有任何工具能一笔笔画清楚。这才是我想做北京地铁足迹地图记录工具的真正原因。不是要给地铁爱好者的收藏夹再添一个花哨页面而是想回答一个很朴素的问题我每天走过的这张城市网到底覆盖了多大的范围。现在这个工具已经上线代码也开源了。这篇文章把它的设计思路、实现链路和踩过的坑写清楚给准备做类似地图工具、或者单纯想给自己的生活留一份轨迹数据的人一些参考。这里先给出我的核心判断一个足迹地图工具的价值不在于把地图画得有多好看而在于是否形成了“输入记录—路径补全—持久化—回溯”的数据闭环。如果只是画一条线、亮几个点那它和一张静态效果图没有区别。真正让足迹地图有意义的是它能持续使用、持续积累最终变成属于你自己的城市时间线。1. 先想清楚我们真正要记录的是什么1.1 地铁站是城市骨架的“锚点”要理解足迹地图为什么用地铁站做节点得先把城市地图的呈现方式想明白。城市很大但我们真实的活动半径其实是由少数几个锚点撑起来的家、公司、常去的商圈、朋友的小区、约会的电影院。这几个锚点之间交通线路就是连接线。地铁站恰好同时具备锚点和连接线两种属性。它是一个有名字、有坐标、有线路归属的空间节点。记录你坐过哪些站表面上是在记录交通轨迹实际上是在记录这座城市对你开放过多少区域。这也是为什么我不建议只用 GPS 画一条漂移轨迹。GPS 轨迹依赖信号抖动大、没有语义回看时很难知道那条曲线到底意味着什么。而地铁站是“有名字的地理坐标”一看到“天通苑”“西二旗”“国贸”这几个字不需要地图你脑海里就已经自动把城市地图展开了。1.2 足迹记录不只是打卡而是把碎片经历变成个人时间线最初做这个项目的时候很多朋友会问这和地铁站打卡 App 有什么区别打卡的本质是“当下验证”到过一站盖一个章是离散的收集行为。足迹记录的本质是“时间与空间的堆积”。记录下来的每一笔行程都包含了日期、起始站、终点站、换乘线路这些信息。当这些记录攒到一定量级它们就会变成一条个人时间线你住过哪个区域工作在哪个片区周末的活动半径从哪一年开始变大哪条新线开通之后你第一时间去坐了。这些信息不是通过回忆拼凑出来的是从数据里长出来的。所以我在设计记录字段时刻意保留了乘车日期和乘坐状态。这看起来只是两个普通字段但它们才是让足迹地图从“空间展示”升级为“时间回溯”的关键。1.3 一个判断足迹工具的价值不在画图在数据闭环做开发时我一直提醒自己不要被地图可视化牵着走。地图只是界面真正的核心是数据闭环。一个合格的足迹地图记录工具至少要满足三个环节输入环节要足够轻。记录一次行程不能要求用户逐站打勾否则新鲜感一过就弃用了。路径补全要可靠。用户只需要输入起点、终点和换乘线路系统要能自动把途径站点点亮。数据要能导出。记录的最终归属是用户自己。如果数据只存在应用里应用一旦关闭所有痕迹就消失了。这个判断直接决定了工具形态。它不能只是一个照着地图画线的静态页面必须是一个能记录、能保存、能恢复的小系统。开源版本的核心就是把这条数据闭环跑通。2. 核心链路拆解数据、记录与路径补全2.1 站点数据从哪来又要整成什么样北京地铁站点数据是项目的基础也是最耗费耐心的部分。常见的数据来源包括公开的线路图 JSON、地图平台的 GeoJSON 数据、百科站点列表以及地铁族爱好者整理的线路时刻表。但不管从哪个来源拿数据都需要统一整理成项目能识别的结构。这个工具里用的站点数据大概类似这样{ line: 1号线, stations: [ { id: bianmen, name: 苹果园站, lng: 116.178, lat: 39.926, transfers: [6号线] } ] }字段不需要太多但有几个点非常重要id必须是稳定的唯一标识不能直接用中文站名做 key。原因后面会讲。坐标建议统一使用 GCJ-02 国测局坐标避免和国内底图服务偏移。transfers数组要标注换乘线路这是路径补全的关键依赖。数据整理完成后最好人工抽样检查 50 到 100 个主要站点确认名称、坐标、换乘关系没有大问题。数据源没有一个能直接落到“开箱即用”大多数情况要经过清洗和去重。项目里保留的就是一份清洗后的静态 JSON 数据不会实时从在线地图拉取这样加载快也方便离线使用。2.2 一次乘车的记录模型输入起终点而不是逐站点击给用户提供“逐站点亮”的方式是最直觉的但也是最反人类的。一趟常规通勤可能要经过 10 个站换乘 2 次如果每坐一站都要打开手机标记一下坚持不了三天。更合理的记录模型是用户输入起始站、终点站、乘坐日期。系统自动补全把这条线路上的途径站点一次性点亮。如果行程涉及换乘则要补充换乘线路。例如从中关村到国贸系统自动判断需要乘坐 4 号线换 1 号线那两个线路上从起点到目的地的所有站都会被标记为“已乘坐”。这个模型才符合真实乘坐动作。用户记住的永远是自己从哪站上车、在哪个站下车、中间换了几条线而不是沿途一共经过了几个站。2.3 换乘路径补全从 A 到 B如何把中间站自动点亮路径补全是这个工具最核心的逻辑。编写时顺着一个简单思路做先把一条线路的站点按顺序排列再在换乘站把两条线拼接起来。以“4号线换1号线”为例找到 4 号线的站点顺序从“中关村站”到“西单站”之间经过的所有站全部标记为已乘坐。在换乘站“西单站”切换到 1 号线。找到 1 号线的站点顺序从“西单站”到“国贸站”之间的所有站全部标记为已乘坐。伪代码大概是这样的def mark_ride_path(start_station, end_station, lines): current_line lines[0] current_station start_station for line in lines: stations line_stations[line] idx_current find_index(stations, current_station) idx_end find_index(stations, end_station) if line lines[-1] else find_transfer_index(line, lines, lines.index(line) 1) # 标记该线路上从 idx_current 到 idx_end 之间的所有站 mark_stations(stations, idx_current, idx_end) current_station idx_end实际编码时要注意线路顺序可能正反不一致。有的数据源里 4 号线是从安河桥北往天宫院排列有的是反的。所以补全逻辑里必须做方向判断不要假设数据源里的站点顺序就是正向的。2.4 环线、分叉线和同名站点的处理北京地铁线网有几类特殊情况是所有类似工具都会遇到的环线10 号线、2 号线这种闭合线路。不能简单地按起点到终点截取要判断走内环还是外环或者干脆默认按短路径计算。分叉线一些站点发车方向不同会分叉。此时要结合用户的换乘方案来判断实际经过的站点而不是单纯按当前线路所有站点点亮。同名换乘站不同线路都有“西直门站”但如果站点 ID 不一致就会出现第二次坐 4 号线经过西直门时1 号线的西直门站没有被点亮。处理思路很简单站点归属以站点 ID 为准而不是以站名为准。换乘关系必须通过transfers字段显式关联同一座换乘站的多线路名在数据里要指向同一个 ID。遇到环线时我的建议是不追求绝对精确优先采用“短路径优先”策略。如果两个方向距离差不多默认按数据源中的方向顺序处理但在页面结果里把环线标识出来让用户能自行判断是否需要切换方向。3. 技术选型与可视化实现3.1 技术架构推荐纯前端优先后端看需求再加这个项目的技术架构如果只服务于个人记录我会优先推荐纯前端方案。原因很直接部署成本低可以直接扔到静态托管平台。个人数据存储在本地或自己的数据库不需要复杂的鉴权体系。站点数据本身就是静态 JSON不需要后端实时计算。一个可行的架构组合是层级选型原因前端框架Vue 或 React组件化方便管理底图、状态面板和记录表单地图渲染Leaflet / MapLibre GL / ECharts GL轻量支持自定义覆盖物不依赖商业 API Key底图瓦片高德、百度、Carto 等 2D 瓦片国内场景优先选用 GCJ-02 坐标的底图数据存储localStorage 或 SQLite个人使用足够导出 JSON 即可备份部署GitHub Pages / Gitee Pages / Nginx / Docker按是否带后端灵活选择如果后续想实现多设备同步、分享页面、游客查看足迹那再加一个轻后端即可通常一个 Node.js 或 Python 的服务就够了。做这类工具时最常见的错误是第一版就上复杂权限体系反而拖慢核心闭环。3.2 地图渲染的三层分离底图、线路、站点整个地图可视化可以拆成三层底图层负责展示真实地理环境保持视觉弱化不需要太强的 POI 展示。线路层把每条地铁路线的 Polyline 按主题色绘制出来。未乘坐线路用浅色绘底已乘坐线路在足迹回看模式下用主色高亮。站点层在地铁站点位置绘制圆点或图标。已乘坐使用高饱和度色未乘坐使用灰色。分层最重要的收益是渲染逻辑不会纠缠在一起。切换“足迹回看模式”时只需要改动线路层和站点层的数据源底图不动逻辑非常清晰。// 站点状态数据示例 const stationStatus { bianmen: { visited: true, lastVisit: 2024-11-02 }, gongzhufen: { visited: true, lastVisit: 2024-11-02 }, muxidi: { visited: false } };3.3 数据存储、导入导出与备份足迹记录数据建议按条结构化保存每一条记录至少包含乘坐日期起始站 ID终点站 ID换乘线路数组途经站点 ID 数组补全后生成保存到 localStorage 的好处是无需后端、刷新不丢。但 localStorage 有容量上限也不适合长期唯一性存储。所以我强烈建议在设置页提供 JSON 导出功能。导出文件结构大概像这样{ records: [ { date: 2024-11-02, from: zhongguancun, to: guomao, routes: [4号线, 1号线], stations: [haidianhuangzhuang, xisi, xidan] } ], version: 1.0 }记录文件的版本号字段很重要。以后一旦调整站点 ID 规则可以靠版本号做数据迁移。这算是一个通用经验给任何导出数据都留下version字段能救回很多次因为结构变更导致的“历史数据读不出来”事故。3.4 统计视图怎么加才不会过度设计第一版不需要做太多统计。我建议只保留三个维度已乘坐站点数直接展示整体覆盖进度。已乘坐线路数方便看出你集齐了哪条线。最近乘坐记录按日期倒序列出保持“日志感”。这三个统计的完成度已经足够回答“我在北京地铁里覆盖了多少空间”这个最初的问题。像站点覆盖排行、连续乘坐天数、最常换乘路线这类进阶统计应该等基础闭环稳定后再加。过早加统计视图会让页面变成控制台而不是一个让人愿意持续记录的工具。4. 从自用工具到开源项目我建议补齐的几块拼图4.1 开源前的自查清单个人工具做出来之后自己用得顺手不等于能直接开源。从个人项目变成开源项目最少要过一遍自查清单项目根目录是否有 README能说清楚项目是什么、怎么用、怎么部署。是否有 LICENSE 文件。如果没有法律上默认保留所有权利别人根本不能合法使用。是否已移除本地调试用的 API Key、私密 token、数据库密码。站点数据是否和代码分离。这样其他人换城市时不需要改动源码只需要替换数据文件。是否提供了最小可运行示例。别人 clone 下来能不能一条命令跑起来看效果。是否写了已知限制。比如“线路数据更新到某年某月”“环线方向默认按短路径计算”。开源并不意味着要写完善的项目管理文档但至少要让人在 10 分钟内能跑起来并理解项目结构。4.2 许可证选择和平台发布许可证的选择经常被新手忽略。常见选择有两个方向MIT 许可证允许别人商用、修改、再分发只需要保留版权声明。适合希望项目被广泛复用的工具。GPL 许可证要求衍生作品也必须以 GPL 协议开源。适合希望项目保持开源的分享者。如果你的项目主要价值在数据整理和设计思路可以用 MIT引导更多人基于你的代码去适配其他城市。如果希望项目生态始终保持开放可以选择 GPL。发布平台方面代码托管到 GitHub 和 Gitee 都是常见选择。国内用户通常更习惯从 Gitee 访问但国际关注度主要在 GitHub。不冲突可以两边同步发布只要在各平台仓库的 README 里标明原文仓库地址即可。4.3 部署方式静态页、Docker 与 Nginx如果项目是纯前端方案部署极其简单。构建后打包出一个dist/目录扔到任意静态托管或 Nginx 里就完成了。# 前端项目常见构建流程 npm install npm run build # 构建后输出 dist/ 目录配置 Nginx root 指向该目录即可如果带了轻后端则可以考虑 Docker 部署。一个极简的 Dockerfile 示例结构大概是FROM node:20-alpine WORKDIR /app COPY package*.json ./ RUN npm install --production COPY . . EXPOSE 3000 CMD [node, server.js]这里需要注意的是如果项目里的底图服务需要域名白名单在本地部署和线上部署时要提前把访问域名配置进底图服务的白名单否则页面能加载但地图瓦片会挂掉。4.4 开源项目的边界不做免费客服也要有反馈模板开源项目最容易被忽略的坑是作者被铺天盖地的 Issue 淹没。一个好的做法是在 Issue 模板里要求用户提供运行时信息浏览器版本、部署方式、站点数据版本、控制台报错截图。这样能大幅过滤掉无效反馈。也要在 README 里明确写出维护边界。比如“该项目只确保北京地铁数据下运行正常其他城市需自行替换数据文件”“不处理依赖外部数据服务的实时线路运营问题”。这不是逃避责任而是让开源项目保持健康维护节奏的必要手段。5. 开发过程中最容易踩的坑与排查思路5.1 数据坑站点名和坐标不一致北京地铁站点数据最大的坑不是数据量不够而是来源混乱。同一个站在不同来源里可能叫法不同、坐标不同、所属线路顺序不同。比如有些数据源使用旧版站名有些使用工程名有些坐标是 WGS-84有些是 GCJ-02叠到国内底图上一看站点偏移几十米到几百米。经验在项目开始阶段就建立一个“站点收编表”把不同来源的站点信息逐条对齐。只依赖单一数据源通常会留下大量隐性错误。具体排查路径先看单个站点的坐标是否落在底图上正确位置。再看换乘站是否在所有相关线路中都使用了同一个 ID。最后检查整条线路的站点顺序是否存在明显的绕路或跳站现象。这一步不能跳过因为后面的路径补全完全依赖数据正确性。数据一旦错了路径补全全崩。5.2 逻辑坑换乘站被重复点亮换乘站重复点亮是足迹地图的经典 Bug。例如西直门站在 2 号线、4 号线、13 号线中都会出现。如果你保存的乘坐记录只按线路处理就会在换乘时出现同一个站点点亮两次。而且两个记录并不是同一份数据后续统计站点数时会多算。解决方案是引入“站点访问状态表”访问状态以站点 ID 为键同一个 ID 只会被点亮一次。换乘站的线路归属只影响线条颜色不影响访问标记。这段逻辑看起来简单但很多人做的时候会忽略直到统计站点覆盖率时才发现总数不对。5.3 性能坑页面卡顿的排查顺序站点少时性能问题不明显但北京地铁站点总数超过几百个后如果直接给每个站点渲染一个 DOM marker页面就会明显卡顿。尤其是地图缩放旋转、轨迹回放时帧率会肉眼可见地下降。排查顺序建议这样做先看渲染节点数量当前地图范围内同时渲染了多少个 marker超过 300 个是否启用了聚合或 Canvas 绘制。再看数据源大小站点 GeoJSON 是否包含大量冗余字段网络加载耗时和解析耗时是多少。再看底图资源是否在弱网环境加载了高清遥感瓦片是否同时加载了多套底图。最后看交互代码地图缩放时是否执行了不必要的全量重绘比如每次 zoom 都重新生成所有站点图层。多数情况下把 DOM marker 换成 Canvas 或 SVG 图层卡顿问题就解决了大半。这个阶段的优化收益远大于去纠结框架选择。6. 适用边界、使用路径和后续规划6.1 适合谁用不适合谁用任何工具都有自己的边界。这个足迹地图最合适的使用者是经常坐地铁通勤、出差希望对城市空间有直观感知的人。对地铁线路和城市交通变迁感兴趣的人。准备按线路“刷站”、把自己住过的城市走透透的人。想做城市足迹类可视化项目参考数据结构和实现路径的开发者。不适合的使用场景包括需要精确统计每一趟班次时刻、票价和进出站时间的通勤分析。这需要接入交通卡或乘车码的明细数据手动输入模式的颗粒度达不到。需要边走路边实时记录户外轨迹。这是纯粹的 GPS 轨迹记录工具不是地铁站足迹工具。需要跨城市实时更新的运营数据。如果每个城市的线路都在不断增加可持续维护的压力会非常大开源协作是更可行的方式。判断标准只有一句话如果你的目标是通过站点数据回溯自己和城市的关系这个工具是合适的如果你需要的是一份精确的交通消费账单它不适合。6.2 首次使用的最短可行路径不建议第一天就疯狂录入历史行程。更建议按最短路径先让数据闭环跑起来第一步确认站点数据能正常加载地图上能看到完整线网和站点。 第二步连续一周记录上下班通勤每次只记起点、终点和换乘线路。 第三步导出一次 JSON 备份确认导出文件结构完整。这三步做完你才真正理解了工具的输入模型和数据回流方式。接下来再按自己的需求去补历史记录比如把刚来北京时住过的区域、以前常和朋友约饭的商圈一条一条补进去。每补一笔地图就会亮一批站点那种“原来我都去过这些地方”的体感是看任何 App 截图都不能替代的。6.3 从记录到探索这个项目还可以长成什么样现有版本解决的是“记录已经发生过的足迹”但更有趣的方向是“用足迹反过来推动探索”。后续比较适合的演进方向我从易到难排一下覆盖进度页展示总车站覆盖比例、已乘坐线路进度、还剩多少站没去过做成可分享的卡片。新线开通提醒在站点数据更新后第一时间识别新开通站点并在足迹图上高亮。多城市模板把数据整理方式沉淀成模板让其他城市的使用者替换数据文件即可复用。周末随机刷站模式随机推荐一个少去区域的地铁站鼓励使用者通过地铁探索城市新区。这里最有价值的是第 3 条。足迹地图的真正终点不应该是北京一个城市而应该成为每个人记录自己城市蔓延史的一套通用工具。北京只是第一个数据样本。回到最初的问题。走过这座城市这么多站点最终被点亮的地图不是给别人看的成绩单而是一张属于你自己的城市时间线。北京地铁在今天只是线网图上几百个点组成的网络但在足迹记录完成的那一刻它就有了温度哪一年你开始不再去那个站哪条新线开通后改变了你的通勤路径哪次跨城约饭让你第一次接通了原来不相邻的两片区域。工具本身并不复杂。复杂的是把一份静态地图变成一条持续累积的个人数据流。这也是开源这件事真正吸引我的地方——不需要每个人都从零开始整理数据、画底图、写路径算法只要一个人把轮子做好其他人就可以把更多城市、更多故事叠加上去。如果你也想做类似的东西我的建议只有一个先别想着把所有功能做完先跑通“记录一次行程点亮一路站点导出一次备份”的小闭环。剩下的优化、美化、统计都会在这个闭环稳定生长出来。
