共计 3654 个字符，预计需要花费 10 分钟才能阅读完成。
每次要出门旅行之前，我的行程信息总是散落在好几个地方。机票确认邮件躺在邮箱里，酒店预订是另一封邮件，想去的餐厅和景点用某地图软件收藏了一堆，预算我习惯用记账软件单独记，跟同行的朋友讨论又得切回聊天工具，临出发前还得翻一份不知道存在哪里的打包清单。等到真正上路，需要查某个信息的时候，我经常想不起来它到底在哪个 App 里。这种割裂感困扰了我很久，直到我开始认真寻找一个能把这些东西全部装进同一个地方的工具。
市面上不是没有商业旅行 App 想解决这个问题，但它们大多有同样的毛病。要么把核心功能锁在订阅墙后面，免费版只能建一两个行程；要么数据完全攥在厂商手里，哪天公司倒闭或者砍掉这条产品线，你积累的所有旅行记录就跟着消失；再要么就是塞满了广告和酒店推广，规划行程变成了被推销的过程。对于我这种既想要功能完整、又在意数据自主权的人来说，自托管的开源方案才是真正合口味的答案。这次想跟大家聊的 TREK，就是我最近找到的、目前完成度最高的一个。
TREK 到底是什么
TREK 的自我介绍很直白：一个自托管的、支持实时协作的旅行规划器，内置地图、预算、打包清单、旅行日记和 AI。这个项目在 GitHub 上已经积累了七千八百多个 star，采用 AGPL-3.0 协议开源，本身是一个渐进式 Web 应用（PWA），意味着你可以把它像原生 App 一样装到手机桌面上使用。
从技术栈上看，TREK 的选型相当现代。前端用的是 React 19 加 Vite，TypeScript 全量覆盖，样式走 [[Tailwind CSS]]，状态管理选了轻量的 [[Zustand]]。后端是 [[NestJS]] 11 跑在 Node.js 22 上，数据库直接用 SQLite，整个数据库就是一个 ./data/travel.db 文件。这种选型对自托管场景特别友好，不需要你额外去部署 PostgreSQL 或者 Redis，一个容器就能跑起来，备份的时候把那个 db 文件和上传目录拷走就行。地图部分同时支持 [[Leaflet]] 和 [[Mapbox GL]]，实时同步靠原生 WebSocket 实现。整个项目百分之九十九都是 TypeScript 写的，代码风格统一，对想自己改两行的人来说门槛不算高。
我之所以强调技术栈，是因为自托管工具的长期价值很大程度上取决于它的工程质量。一个用 NestJS 这种结构清晰的框架、把类型系统用满的项目，通常意味着它后续维护得动、社区也接得住。那些用一堆老旧依赖拼起来的自托管项目，往往装上之后就再也没法升级了。
把旅行的每个环节都装进一个地方
TREK 真正打动我的，是它对旅行全流程的覆盖之完整。我把它的功能拆成几个我实际会用到的部分来说。
行程规划是核心。它提供一个拖拽式的按天规划器，你可以把景点、餐厅、活动拖到具体的某一天，也支持跨天移动，临时改行程的时候不用重新输入。配套的互动地图能显示 3D 建筑、地形、聚合标记和路线可视化，地点搜索既可以接 Google Places，也可以用免费、无需 API key 的 [[OpenStreetMap]]。更省心的是导入能力，它支持从 Google 地图或 Naver 地图的收藏列表导入，也吃 GPX、KML、KMZ、GeoJSON 这些格式，等于把你过去在各个地图软件里攒的收藏一次性搬过来。它还内置了路线优化和天气预报，天气数据来自 Open-Meteo，提供十六天预报，同样不需要 key。
费用管理这一块做得超出我的预期。TREK 把它形容为 Splitwise 式的开销追踪与分摊，支持多币种结算。对于经常跟朋友拼房拼车的旅行来说，谁付了机票、谁垫了餐费、最后怎么算清账，这些原本要靠另外一个 App 解决的事情，现在直接在行程里搞定了。预订管理也很贴心，机票、住宿、餐厅的预订信息可以通过邮件或 PDF 导入，不用手动一条条录。
打包清单和文档管理解决的是出发前的焦虑。清单支持模板、任务分配和进度追踪，甚至能记录行李重量，对有航空托运限重需求的人很实用。文档管理则可以存放各种附件，单个文件上限五十兆。所有这些东西最后都能通过整本行程 PDF 导出功能打包，导出的 PDF 带封面页、图片和笔记，离线带着走或者打印出来都行。
实时协作是它和单机工具的分水岭
如果说前面那些功能很多自托管笔记工具拼一拼也能凑出来，那么实时协作就是 TREK 真正拉开差距的地方。它基于 WebSocket 做了实时同步，一个人改了行程，其他参与者的界面会立刻刷新，不存在「你改完我没看到、各自维护了一份」的尴尬。多人行程支持基于角色的权限控制和邀请链接，你可以拉朋友进来一起编排，也可以只给某些人查看权限。
更进一步，它把协作做成了一个完整的小生态。组内有群聊、共享笔记、投票和每日签到。规划一次多人旅行的时候，去哪家餐厅可以直接发起投票，临时通知可以发在群聊里，不用再开一个微信群跟行程信息两头跑。在身份认证方面，TREK 的完成度也高得有点夸张，它支持 JWT、OAuth 2.1、OIDC 单点登录，能对接 Google、Apple、[[Authentik]]、[[Keycloak]]，还支持 Passkeys（WebAuthn）和 TOTP 两步验证。对于一个自己折腾了完整身份认证体系的人来说，TREK 能直接接进现有的 SSO，这一点非常省事。
值得单独提一句的是它的 AI 能力。TREK 内置了一个 MCP 服务器，经过 OAuth 2.1 认证，对外暴露了一百五十多个工具和三十个资源。这意味着你可以让支持 [[MCP]] 的 AI 助手直接帮你创建行程、规划每天的安排、生成清单、管理预算。在我看来这是一个相当前瞻的设计，它没有把 AI 当成一个塞进来的噱头按钮，而是把整个应用的能力以标准协议开放出去，让 AI 成为一个真正能操作数据的客户端。
自己动手把它跑起来
聊了这么多，最实在的还是怎么把它部署起来。TREK 的快速启动用 Docker 一条命令就够了，对自托管用户友好得很。
ENCRYPTION_KEY=$(openssl rand -hex 32) docker run -d -p 3000:3000 \
-e ENCRYPTION_KEY=$ENCRYPTION_KEY \
-v ./data:/app/data -v ./uploads:/app/uploads mauriceboe/trek
跑起来之后访问 http://localhost:3000 就行。首次启动它会自动生成一个管理员账号，凭据会打印在容器日志里，你也可以提前用 ADMIN_EMAIL 和 ADMIN_PASSWORD 环境变量指定。这里那个 ENCRYPTION_KEY 是用来加密敏感数据的，一定要妥善保管，弄丢了数据就解不开了。
如果你想跑生产环境，官方提供了 Docker Compose 配置，里面带了只读文件系统、丢弃多余 capabilities、健康检查这些安全加固。喜欢用 Kubernetes 的话，还有现成的 Helm chart，加一个仓库就能装。反向代理方面，Nginx 和 [[Caddy]] 都行，唯一要注意的是必须放行 /ws 路径的 WebSocket 升级，否则实时同步会失效，这是部署这类应用最容易踩的一个坑。
有几个细节我必须提醒一下，这些都是从官方文档里挖出来的避坑点。第一，数据持久化在挂载的 data 和 uploads 两个卷里，升级镜像永远不会动它们，所以放心更新。第二，千万不要把卷挂载到 /app 这个路径，那会把应用代码本身盖掉，直接导致启动失败，这是一个很反直觉但很致命的错误。第三，如果你在 TLS 终止的反向代理后面跑，记得设 FORCE_HTTPS=true 并配好 TRUST_PROXY，不然回调地址会出问题。第四，TREK 支持自动备份，可以配置保留策略，建议一开始就把它打开，旅行数据攒久了还是挺有价值的。
最后还得说一句许可证的事。TREK 用的是 AGPL-3.0，这是一个传染性很强的协议。如果你只是自己用，或者给家人朋友用，完全没有任何问题。但如果你修改了 TREK 并把它作为网络服务提供给第三方，那你的修改也必须以同样的协议开源出来。对绝大多数自托管用户来说这条无关紧要，但如果你打算基于它做商业产品，务必先把许可证条款看清楚。
最后
TREK 解决的不是某一个具体的痛点，而是旅行信息四处散落这个结构性的麻烦。它把行程、地图、预算、清单、文档、协作、AI 全部收进同一个自托管的应用里，让你不用再在六七个 App 之间反复横跳，更重要的是，所有数据都留在自己的服务器上，不受任何厂商的订阅墙和生命周期摆布。
对我来说，TREK 的吸引力一半来自功能的完整，一半来自它背后那套扎实的工程。NestJS 加 React 19 的现代技术栈、把类型系统用满的 TypeScript 代码、标准化的 MCP 接口、考虑周到的部署文档，这些都让我相信它不是一个昙花一现的玩具，而是一个能长期陪着我走下去的工具。如果你和我一样，既想要一个一站式的旅行规划器，又不愿意把数据交出去，那么花半小时把 TREK 部署起来，大概率不会让你失望。我打算在下一次出行规划的时候就正式用上它，到时候再回来分享一些真实使用中的体验和细节。
