不想再用表格做旅行攻略?这个开源旅行规划器可以自建

行程、预算、地图、打包清单，一个开源项目全包了

每次三五个朋友约好出去玩，最先热闹起来的往往不是行程，而是“咱们先建个共享文档吧”“地图发我一份”“账到时候群里再算”“打包清单各记各的”。一趟旅行还没开始，信息已经散在四五个地方。很多人最后会发现，真正在用的不是某一个 App，而是微信群。

TREK 算是盯上了这个麻烦。它是一个基于 NestJS + React 的开源旅行规划器，能自己部署，也支持多人同时编辑。如果你愿意花点时间搭一套自己的系统，它可以把行程、地图、预算、打包清单尽量塞到同一个地方，不用再在表格、聊天记录和各种商业 App 之间来回跳。

行程和地图能联动

我第一次用 TREK 的时候，是把它当一个能一起编辑的行程板。在里面按天排地点，顺序可以拖拽，某一天的内容也能挪到另一天。地图不是孤立附件，和行程是联动的：你在行程里加了地点，地图上就会同步出现标记。它支持 Leaflet 和 Mapbox GL，走户外或多点城市路线时，路线可视化会直观一些。

对我而言，这类工具最有用的时刻，不是“看一个漂亮的旅行计划”，而是临出发前临时改行程：有人想加一个中途点，有人要提前回酒店，拖拽调整后，其他人打开就能看到最新版，不用再发截屏说明。

多人协作这件事，它真的在解决

很多工具都说支持多人，但 TREK 的协作更像一个共享工作台。WebSocket 实时同步的意思是，你改预算的时候，负责行程的人也能立刻看到变化。它可以按旅程邀请成员，也支持基于角色的权限控制；组织多人长途旅行时，可以把不同模块分给不同人维护，比如一个人管机票酒店，一个人管每日行程，一个人管预算和分摊。

比共享表格好的一点是，它不是平面表格，而是把地点、时间、费用、附件这些不同类型的信息组织在同一个旅程对象里。你不用再在一张巨大的 Sheet 里同时塞入日期、地址、金额、备注和证件号，最后检索和查看都麻烦。

预算和打包清单也一起收了

旅行里最容易吵起来的两件事，通常是“最后花了多少”和“谁带了什么”。TREK 内置了费用跟踪和分摊逻辑，可以按人、按天查看花费，也支持结账和欠款梳理。虽然没有披露结算逻辑细节，但至少比聊天里口头记账完整一些。

打包清单部分也很实用：支持分类、模板、成员分配和进度跟踪。出发前谁还没买转换头，谁还没确认签证材料，不用在群里反复点名。它甚至支持把订单、票据、PDF 这类文件直接关联到旅程、地点或预订记录上。也就是说，这次旅行的资料可以尽量收在一套系统里，而不是散在邮箱、微信文件、浏览器下载夹里。

自托管是这个工具最值得注意的点

以上这些能力里，最不像普通 SaaS 的一点，是 TREK 官方明确支持自托管。它能以 Docker 容器运行，挂载数据卷和上传目录后就能使用；也有 Helm Chart，适合想放进 Kubernetes 的人。后台用 NestJS，前端是 React，数据库和文件存储都落在你自己控制的存储里。

这带来的好处是数据可控，适合对隐私敏感的小团队、企业内部出行统筹，或者单纯不想把旅行资料继续往商业平台堆的人。但它也带来了一个现实问题：你需要准备一台能持续运行的服务器、一个域名、HTTPS 条件，以及最基本的运维能力。官方也提醒过，生产环境最好放在 TLS 终止反向代理后面，并确保 WebSocket 升级正常工作。

所以如果你只是想“手机上快速记一下旅行灵感”，自托管 TREK 显然太重了；但如果你本来就有一台 NAS、VPS 或家庭服务器，又正好想给几次多人出游找一个长期可用的统筹系统，它就值得认真看。

适合谁，不适合谁

从现有能力看，TREK 更适合几类人：3 到 8 人的小团体出游，尤其是需要反复调整行程的长途旅行；情侣或家庭，希望把机票酒店、每日安排、预算和打包清单集中管理；数字游民或远程团队，既熟悉自托管，也希望把旅行数据和日常工具统一在自有环境里。

它目前并不适合两类场景：完全没有部署条件、只想在手机上立刻上手的用户；只把旅行规划当成一次性轻量任务、不需要长期协作和归档的人。对后者来说，一个共享 Google Maps 列表加简单表格，可能仍然更轻便。

获取方式

TREK 是开源项目，GitHub 仓库为 https://github.com/mauriceboe/TREK。如果你想先看 Demo 或官方截图，README 里已经列出了仪表盘、行程、地图、预算、地图集等界面参考。

如果你正准备组织一次多人旅行，又被表格和聊天记录搞得头疼，不妨把它当成一次“用自己的方式管旅行资料”的尝试。唯一需要注意的是：自托管不是点一下安装就结束的事，建议先评估自己是否有持续运行和维护这套系统的条件，再决定要不要把它当成主力旅行工具。