TREK 评测：自托管旅行规划器，实时协作与地图深度集成

它解决什么问题，谁需要它

TREK 解决的是多人共同规划一趟旅行时的数据分散问题。日历、地图标记、费用分摊、行李清单、住宿预订，这些信息通常散落在不同应用里，协作时靠截图和消息来回传。TREK 把这些集中到一个自托管实例里，用 WebSocket 实现实时同步，编辑结果对打开同一行程的所有人即时生效。它的目标用户是愿意自己跑服务的团队或家庭，而不是普通消费者。演示站点 demo.liketrek.com 存在，但 README 没有说明它是否长期开放，自托管是明确的使用前提。

核心机制：地图、数据与实时同步如何咬合

TREK 的地图层是可替换的。默认用 Leaflet，也可以切换 Mapbox GL 或 MapLibre GL。OpenFreeMap 不需要令牌，Mapbox 则提供 3D 建筑和地形。地点搜索在配置 Google Places 密钥时使用该服务，否则回退到 OpenStreetMap。地点补全信息来自 OpenStreetMap、Wikipedia、Wikidata 和 Wikimedia Commons，这些数据源通过 Overpass 拉取当前视口内的 POI。行程规划时，拖拽地点到某一天，地图标记会同步落下，这种双向绑定是它的交互核心。路线排序用最近邻加 2-opt 算法，锁定停靠点和酒店锚点不会被移动，路由计算走 OSRM，支持驾车、步行和骑行。公共交通则通过 Transitous 获取门到门方案。每个外部服务都是独立依赖，任何一个失效都会影响对应功能，README 没有说明降级策略。

部署与启动：Docker 镜像与配置开关

README 明确提供了 Docker Hub 镜像 mauriceboe/trek，这是最直接的部署路径。镜像内附带 kitinerary-extractor 二进制，用于解析 EML、PDF、PKPass 等格式的预订确认邮件，这是少数需要额外二进制才能工作的功能。配置上，管理员可以逐个开关功能模块。Lists、Costs、Documents、Collab、Vacay 和 Atlas 默认开启，Journey、Collections、MCP、AI Parsing 和 AirTrail 默认关闭。关闭的模块在 UI 里不显示，但代码仍在，这减少了攻击面但没消除。环境变量 TREK_PLUGINS_ENABLED=false 可以完全关闭插件系统，这是安全敏感部署的明确选项。没有提供 docker-compose 示例或环境变量清单，实际部署时需要从镜像文档或源码里找，这对快速上手是个障碍。

插件系统：沙箱与信任链的取舍

TREK 的插件系统设计得比大多数同类项目谨慎。每个插件运行在独立子进程里，有 63 种可授予的权限，管理员可以编辑出站主机白名单，还设置了内存和 RPC 上限，以及 AI 和通知调用的每日配额。插件可以从官方注册表安装，下载时用 sha256 固定哈希，并对照作者的 minisign 密钥验证。旁加载的 zip 会被标记为未验证。这个设计承认了第三方代码的不可信性，但信任链依赖作者维护密钥和注册表，如果作者不更新，旧插件可能无法通过校验。插件有独立页面，路径是 /plugins/<id>，但 README 没有说明插件 API 的稳定性，版本升级可能导致插件不兼容，这是采用前需要评估的维护成本。

费用与预订：精确到分的分摊和本地时区

费用分摊用整数分存储，支持等额或自定义比例，多个付款人，还有结算建议和结算日志，CSV 导出方便记账。货币汇率在录入时冻结，数据来自 Frankfurter，无需密钥。航班和火车预订支持多段航程、经停点、每段时间和终点时区，内置了 4,045 个机场，所以本地时间解析不依赖外部密钥。住宿预订跨越日期范围，显示在覆盖的每个晚上。预订导入依赖 KItinerary，这是 KDE 的项目，Docker 镜像里带了二进制，但 README 没有说明它的解析准确率。PDF 导出包含封面、地点照片、日记、预订和费用，可选按天分页，这对打印行程单有用。

协作与分享：权限粒度与访客模式

协作是 TREK 的卖点之一。成员可以通过邮箱或用户名添加，也可以把所有权转给他人。访客不需要登录，这是一个低摩擦的参与方式。权限系统把 16 种行程操作映射到管理员、所有者、成员或所有人，粒度细但配置复杂，管理员需要理解每个操作的含义。每个行程有可复用的邀请链接，可设过期时间，管理员还能签发带使用次数限制的注册邀请，新账户直接进入行程。公共分享页面是只读的，无需账号即可查看。群聊支持回复、表情反应和链接预览，还有共享笔记、投票和即将进行的活动列表，这四个组件各自独立开关。这个设计让协作功能可以按需裁剪，但默认全开，新实例需要手动调整。

限制与适用边界：哪些场景它是错误工具

TREK 的复杂度是双刃剑。功能开关众多，每个模块都有外部依赖，比如天气用 Open-Meteo，节假日用 date.nager.at，学校假期覆盖 16 个欧洲国家，这些服务如果不可用，相关功能会静默失败或报错，README 没有说明错误提示方式。对于单人旅行者，TREK 的协作、权限、费用分摊都是多余负担，用简单的笔记应用或电子表格更直接。对于不熟悉自托管的用户，Docker 部署只是第一步，维护升级、备份、外部服务密钥管理都是持续成本。AGPL-3.0 许可意味着任何通过网络提供修改版服务的用户必须开源其修改，这对内部使用无影响，但如果基于它做商业 SaaS，需要谨慎评估。

替代方案与差异

与 TREK 最接近的替代是 Trailarr 或 Wanderlog 这类商业旅行规划器，但它们不是自托管的，数据掌控和定制能力完全不同。在自托管领域，Nextcloud 配合日历和文件应用可以拼凑出类似功能，但没有实时协作和地图集成的紧密度。另一个方向是直接用 Leaflet 或 MapLibre 自己开发，配合 OSRM 和 Overpass，但这需要大量工程投入。TREK 的价值在于把这些组件集成到一个有权限模型和插件系统的应用里，替代方案要么牺牲集成度，要么牺牲自托管。如果只需要地图标记和路线，TREK 会显得过重；如果需要完整的协作和费用管理，它又比 DIY 方案省力得多。

编辑结论

适合需要完全掌控旅行数据、愿意投入部署与维护成本的技术团队或自托管爱好者。不适合追求开箱即用、不想处理插件信任链或不愿接受 AGPL 传染性的用户。采用前应验证 Docker 镜像中 kitinerary-extractor 的可用性，检查插件注册表的签名校验流程，并确认 Frankfurter、Open-Meteo 等外部服务的可用性。TREK 的实时协作与地图能力是真实差异点，但它的复杂度与许可约束决定了它只属于特定人群。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes