# 公交出行开源底座：6个小众神器 ## 概述：这期为什么不挖AI，去挖公交车 连挖这么多期下来，AI 工具链、自托管全家桶、终端神器基本被翻了个底朝天。这期刻意换到一条极少被中文圈写过的赛道：**公共出行的开源数据底座**。你手机上「下一班地铁还有 3 分钟」的背后，藏着一套全世界通用的开放数据标准 GTFS，以及围绕它长出来的完整开源流水线——标准制定、数据体检、接口逆向、城市级到站平台、众包导航 App。这批仓库没有万星光环，却是无数交通部门、出行 App 和地图厂商每天都在吃的基础粮，二次开发和接单空间清晰。覆盖标准、质检、接入、平台、产品五个层级，其中四个仓库 Star 还在两千以下，属于典型的闷声干活型选手。文中星数均为撰写时（2026-09）的约数，以仓库页面实时数据为准。 --- ## 1. [MobilityData/gtfs-spec](https://github.com/MobilityData/gtfs-spec) | 数百星 | 开放治理，持续演进 **一句话定位**：给全世界的公交、地铁、轮渡定一门通用数据语言——GTFS 规范的「法典」本体。 **解决什么痛点**：每家公交公司的时刻表格式五花八门，Excel、PDF、私有数据库应有尽有。做一个跨城市的出行 App，理论上要接一百种接口。GTFS（General Transit Feed Specification）源起于谷歌早年把公交时刻表搬进地图的尝试，后来被推成全球开放标准：把一座城市的公交网络拆成 stops、routes、trips、stop_times、calendar 等十来张 CSV 表，打成一个 zip 就能完整描述「哪条线、几号线、几点几分从哪个站台发车」。 **核心亮点**：这个仓库的看点不在代码量，而在「立法现场」本身——票价、无障碍设施、换乘路径、多语言翻译等扩展仍在通过公开的 RFC 流程演进，任何交通公司和开发者都能提修改意见，由 MobilityData 基金会主持治理。一个字段怎么改，背后是全球几百套系统的兼容权衡，克制得近乎保守，这正是它能活二十年的原因。 **上手难度**：⭐⭐（读懂即可，不用写代码） **适用人群**：出行 App 开发者、政府数据开放部门、数据工程师。**变现思路**：帮中小城市和巴士公司把 Excel 时刻表清洗成合规 GTFS feed，是一門旱涝保收的数据服务；懂规范的人在国内公共交通数字化项目里也是稀缺角色。 --- ## 2. [MobilityData/gtfs-validator](https://github.com/MobilityData/gtfs-validator) | 数百星 | 官方出品，流水线刚需 **一句话定位**：GTFS 数据的官方体检仪，feed 发出去之前的最后一道关卡。 **解决什么痛点**：GTFS 本质是手填的 CSV，人间错误密度极高——一个 `stop_id` 引用写错，整条线路在所有 App 里直接「查无此车」；发车时间跨午夜没处理，末班车永远显示昨天的。靠人肉检查一座城市的几百条线路不现实。 **核心功能拆解**：Java 实现的规则引擎，内置上百条规则，按 ERROR / WARNING / INFO 三级输出结构化的问题报告，精确到文件、行号和实体 ID。提供命令行和网页两种用法，可以单次体检一个 zip，也可以挂进 CI——不少国家的交通数据门户已经把它嵌进发布流水线，不合格的 feed 直接打回重交。想给某个城市或交通公司搭数据门户，这套校验环节几乎是现成的基础件。 **上手难度**：⭐⭐⭐（会跑 Java/Docker，能看懂规则报告） **适用人群**：做政府交通数据平台的服务商、GTFS 数据生产者。**变现思路**：数据治理外包——「发布前体检 + 修复建议」可以包装成年度服务费模式，客户粘性极强。 --- ## 3. [derhuerst/hafas-client](https://github.com/derhuerst/hafas-client) | 千级星 | 小而美，十分钟上手 **一句话定位**：把欧洲几十家公交公司的封闭接口，逆向封装成一个统一的 JavaScript API。 **解决什么痛点**：欧洲大陆的公共交通系统普遍跑在德国 HaCon 公司的 HAFAS 平台上——德国铁路、柏林公交、各地联盟各有各的网页和 App，数据锁死在各自围墙里。想查「从汉堡到柏林下一班火车晚点没有」，得一家一家去爬。 **核心功能拆解**：`npm i hafas-client`，五行代码就能查到柏林下一个发出的地铁班次。它的设计精髓在 profile 机制：每个运营商对应一个适配文件，把各自的接口差异（鉴权方式、报文字段、实时数据格式）挡在同一套 Promise API 之后——查时刻表、查实时延误、查换乘方案、查站点附近的到达信息，函数签名完全一致。社区多年持续新增 profile，是德语区无数通勤工具、聊天机器人和数据可视化的隐形发动机。单维护者长期打磨，文档里连每个接口的坑都写得清清楚楚，是小而美仓库的教科书样本。 **上手难度**：⭐⭐（会 npm 就能跑） **适用人群**：独立开发者、数据爱好者。**变现思路**：做德语区通勤提醒 Bot、企业差排班工具，或者把查询能力封装成付费 API——用户付费意愿在通勤场景里非常成熟。 --- ## 4. [schildbach/public-transport-enabler](https://github.com/schildbach/public-transport-enabler) | 数百星 | 安卓阵营的老兵底座 **一句话定位**：一套 Java 写的公交协议适配层，多款知名开源通勤 App 背后的发动机。 **解决什么痛点**：移动端做公交查询，最重的活不是 UI，而是适配各个地区五花八门的公交信息系统协议。这个库把好几套主流协议的解析、请求构造、实时数据抽取全部封装好，App 开发者只需要面向一个统一的数据模型写界面。 **核心功能拆解**：它最出名的身份是 Öffi 和 Transportr 这两款欧洲老牌开源通勤 App 的底层引擎，覆盖数以十计的国家和城市，从时刻表查询、实时延误到中断通告一应俱全。代码里能看到大量对真实接口怪癖的防御性处理——这正是这类适配层多年踩坑攒下的护城河，后来者想绕开它从零写一遍，代价远比看起来高。适合作为安卓通勤类产品的私有化底座，也适合研究「多协议数据接入层」该怎么设计。 **上手难度**：⭐⭐⭐⭐（Java 库，需要自己搭应用层） **适用人群**：安卓开发者、出海工具团队。**变现思路**：面向欧洲、中东等市场做白标通勤 App，把「城市开通」做成按城市收费的运营服务。 --- ## 5. [OneBusAway](https://github.com/OneBusAway/onebusaway-android) | 千级星（含服务端全家桶） | 长期社区维护 **一句话定位**：开源实时到站平台的鼻祖——「下一班车还有几分钟」这件事的开源答案。 **解决什么痛点**：商业到站预报系统报价高昂，中小城市根本装不起。OneBusAway 起源于西雅图的大学研究项目，后来交给社区和各城市自主运营，把实时到站能力做成了任何人都能部署的开源平台，北美多个城市用它给市民提供官方到站服务。 **核心功能拆解**：整体是「服务端 + App」结构：服务端把 GTFS 时刻表和车辆实时位置聚合成到站预测，通过开放 API 输出；乘客端 App 显示到站倒计时、车辆在地图上的实时位置，还能设「到站闹钟」——快到站了提醒你出门，冬天等车场景里是刚需功能。仓库链接给到安卓端，服务端各模块在 OneBusAway 组织下同源维护，官网有完整的部署文档。这套「时刻表 + 实时流 = 预测」的架构，也是理解整个出行数据行业的最佳教材。 **上手难度**：⭐⭐⭐⭐（服务端是 Java 全家桶，部署有分量） **适用人群**：智慧城市集成商、交通信息化团队。**变现思路**：给二三线城市做公交数字化整体方案——开源底座免授权费，赚部署、定制和运维的钱，模式已被反复验证。 --- ## 6. [trufi-association/trufi-app](https://github.com/trufi-association/trufi-app) | 数百星 | Star 最低，故事最硬 **一句话定位**：官方没有公交数据的城市，怎么做出导航？玻利维亚人给出的答案是：志愿者坐车把线路「踩」出来。 **解决什么痛点**：在玻利维亚科恰班巴，公共交通主力是私营小巴 trufi，没有官方时刻表、没有线路图，谷歌地图一片空白，新来的人和本地人一样抓瞎。发达世界的开源方案在这里全部失效——不是软件问题，是**没有数据**。 **核心功能拆解**：Trufi 协会的打法是先用最土的办法解决数据：志愿者实地坐车记录走向和站点，众包整理成线路数据集，再用自己的跨平台 App 提供换乘导航；数据生产、校验、导航展示整套流程全部开源，任何一座「数据空白城市」都可以照抄这套模式起步。它提醒所有做地图和出行的人：这个星球上大多数城市的公交，其实都没有被数字化。对国内团队来说，这套模式平移到园区班车、景区接驳、县城乡村公交等「封闭场景」，就是现成的产品模板。 **上手难度**：⭐⭐⭐（定制 App 需要前端开发，数据采集靠运营） **适用人群**：新兴市场创业者、公益科技团队、做封闭场景接驳的企业。**变现思路**：园区/景区/县域的「小巴导航」整体交付，数据采集运营 + App 定制双收费。 --- ## 横向对比 | 仓库 | 层级 | Star（约） | 上手难度 | 适用场景 | |---|---|---|---|---| | gtfs-spec | 数据标准 | 数百 | ⭐⭐ | 读懂全球公交数据语言 | | gtfs-validator | 数据质检 | 数百 | ⭐⭐⭐ | feed 发布流水线、数据治理 | | hafas-client | 接口接入 | 千级 | ⭐⭐ | 欧洲实时数据聚合、快速原型 | | public-transport-enabler | 接口接入 | 数百 | ⭐⭐⭐⭐ | 安卓通勤 App 底座 | | OneBusAway | 城市平台 | 千级 | ⭐⭐⭐⭐ | 城市级实时到站服务 | | trufi-app | 终端产品 | 数百 | ⭐⭐⭐ | 无官方数据城市、封闭场景 | ## 数据怎么流：一张图看懂这条开源栈 ```mermaid flowchart TD A["GTFS 数据标准"] --> B["gtfs-validator 体检"] B --> C["城市数据门户"] A --> D["hafas-client 接入"] A --> E["协议适配层"] D --> F["通勤App与机器人"] E --> F C --> G["OneBusAway 到站平台"] C --> H["Trufi 众包导航"] ``` ## 本期之最 - **最值得立即尝试：hafas-client** —— `npm i` 一行命令，十分钟就能查到柏林下一班地铁，是把「开源出行栈」从概念变成体感的最快入口。 - **最有商业潜力：OneBusAway** —— 城市级平台 + 免授权费开源底座，正好卡在二三线城市公交数字化的预算甜蜜点上，集成商模式清晰。 - **最被低估：trufi-app** —— Star 数量垫底，却解决了一颗星球上大多数城市「根本没有数据」的真问题；它证明开源出行栈的下一波增长在「数据生产」而不是「算法」。 ## 参考来源 1. [MobilityData/gtfs-spec](https://github.com/MobilityData/gtfs-spec) — GTFS 规范本体与公开治理流程 2. [GTFS 官网](https://gtfs.org) — 标准文档、案例与生态总览 3. [derhuerst/hafas-client](https://github.com/derhuerst/hafas-client) — 各运营商 profile 列表与 API 用法 4. [OneBusAway 官网](https://www.onebusaway.org) — 项目背景、部署文档与使用城市 5. [Trufi Association](https://www.trufi.app) — 众包公交数据模式介绍 6. [schildbach/public-transport-enabler](https://github.com/schildbach/public-transport-enabler) — 支持的协议与覆盖范围说明 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。