TREK：一个野心超出“旅行 App“本身的自托管协作规划平台
TREK：一个野心超出"旅行 App"本身的自托管协作规划平台
核心定位：这不是 Wanderlog 的简单替代
TREK 的定位需要放在两条坐标轴上来理解。
横轴是功能成熟度：自托管旅行规划工具这个赛道历史上都是"功能残缺品"——要么有地图没预算，要么能协作没离线。TREK 用拖拽行程、WebSocket 实时协作、多货币账单、打包清单、旅行日记、PWA 离线覆盖了整个旅行生命周期，这本身就是一次渐进整合，不是范式突破。
纵轴是架构理念：真正让 TREK 区别于同类项目的，是它把AI 当成"另一个客户端"而非"特殊功能"来处理——内置的 MCP（Model Context Protocol）服务器采用与人类用户完全一致的 OAuth 2.1 + 27 个细粒度 scope + 速率限制体系。这是 2025 年之后 AI 原生应用的正确姿态，值得单独展开。
截至 2026 年 7 月，项目已有10,100+ GitHub Stars，最新版本 v3.2.1，1338 次提交，不是玩具项目。
最关键的机制：MCP 作为"AI 权限边界"的参考实现
TREK 的 MCP 集成是整个项目最值得深思的设计点。
大多数应用集成 AI 的方式是暴露一个粗粒度的 API key，或者让 AI 直接读数据库——要么太宽松，要么需要重新建一套权限体系。TREK 的做法是：MCP 服务器与人类用户走同一套 OAuth 2.1 授权流，150+ tools 和 30 个 resource 都挂在 27 个 scope 下，分属 13 个权限组。AI 助手（比如 Claude、Cursor）访问你的行程数据时，它的权限边界和你授权给任何第三方应用是完全等价的，而不是"管理员级别的后门"。
这解决了一个真实痛点：当你把旅行数据放在自己服务器上，又想用 AI 帮你做规划时，不应该让 AI 拥有比你信任它的程度更多的权限。TREK 的方案是目前开源项目中少数把这个问题想清楚的。
Addon 架构是另一个聪明设计——MCP 的工具列表会根据哪些 Addon 被管理员启用而动态调整。这意味着关掉 Atlas（访问国家地图）后，MCP 就自动失去对应工具，权限边界是实时收缩的，而不是靠约定。
技术栈选择：不赶时髦，每个选择对应具体需求
| 选择 | 理由 |
|---|---|
| NestJS 11 + Node.js 22 | module/controller/service/guard 分层适合多模块+多权限的复杂业务 |
| SQLite（better-sqlite3） | 单文件零运维，自托管场景无需单独数据库进程，支持 at-rest 加密 |
| WebSocket（ws 库） | 直接用 Node.js 原生库，不引入 Socket.io 复杂度 |
| Zustand 代替 Redux | 中小型前端项目够用的轻量 state 管理 |
| Leaflet 优先，Mapbox 可选 | 默认开源免费，高端 3D 地图按需付费 |
| React 19 + Vite + TypeScript | 占代码库 98.3% 是 TypeScript，工程严格性高 |
这套栈在 2026 年没有任何"前沿感"——这恰恰是它值得信任的原因。成熟栈意味着更好的社区支持、更容易招人维护、更少的踩坑风险。
快速部署（30 秒启动）
最简单方式（单命令）：
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，首次启动自动初始化管理员账号（密码打印到容器日志）。
生产环境 Docker Compose（含安全加固）：
services: app: image: mauriceboe/trek:latest container_name: trek read_only: true # 根文件系统只读 security_opt: - no-new-privileges:true cap_drop: - ALL # 丢弃所有 Linux Capabilities cap_add: - CHOWN - SETUID - SETGID tmpfs: - /tmp:noexec,nosuid,size=64m ports: - "3000:3000" environment: - NODE_ENV=production - ENCRYPTION_KEY=${ENCRYPTION_KEY:-} # openssl rand -hex 32 - APP_URL=${APP_URL:-} # OIDC + 邮件链接必填 # - FORCE_HTTPS=true # 仅在 TLS 代理后面使用 # - TRUST_PROXY=1 volumes: - ./data:/app/data - ./uploads:/app/uploads restart: unless-stopped healthcheck: test: ["CMD", "wget", "-qO-", "http://localhost:3000/api/health"] interval: 30s⚠️关键陷阱：绝不要挂载
-v ./app:/app。这会遮盖镜像内的应用代码，导致Cannot find module 'tsconfig-paths/register'崩溃。只挂载./data和./uploads两个目录。
Kubernetes/Helm：
helm repo add trek https://chart.liketrek.com helm repo update helm install trek trek/trek安装为 PWA（无需应用商店）：
- iOS：Safari → 分享 → 添加到主屏幕
- Android：Chrome 菜单 → 安装应用
功能全景
| 模块 | 核心能力 |
|---|---|
| 🧭 行程规划 | 拖拽日程、Leaflet/Mapbox 交互地图、3D 地形、路线优化、16 天天气预报 |
| 🧳 旅行管理 | 航班/住宿/餐厅预订追踪、多货币费用分摊（类 Splitwise）、打包清单、PDF 导出 |
| 👥 协作 | WebSocket 实时同步、角色权限、SSO（OIDC）、2FA、Passkeys（WebAuthn） |
| 📱 移动/PWA | iOS/Android 可安装、离线缓存（Workbox）、全屏原生体验 |
| 🤖 AI/MCP | 内置 MCP 服务器、150+ 工具、OAuth 2.1 授权、27 个权限范围 |
| ⚙️ 管理后台 | 20 种语言、Addon 开关、SMTP 通知、定时自动备份、用户管理 |
Addon 扩展模块（管理员可按需开启）：
- Atlas：访问国家地图、心愿单、旅行统计、连续旅行天数追踪
- Journey：杂志风格旅行日记，支持 Immich/Synology 照片集成
- Vacay：个人假期日历，内置 100+ 国家节假日
- AirTrail：连接自托管 AirTrail 实例同步航班数据
- Collab：群聊、共享笔记、投票、每日打卡
交叉验证
以下两个独立信源对 TREK 的评价与原文基本吻合，但各有补充：
① Text Matrix（txtmix.com，2026年6月25日）对 TREK 做了系统性工程评估，总结为"自托管优先 + 实时协作 + AI 原生集成的完美三角"，并指出 TREK 是"2026 年自托管工具的新高度"，与原文观点高度一致。该文章特别强调了 AGPL-3.0 协议对商业用途的约束——这是原文 GitHub README 没有显著突出的风险点——如果企业修改 TREK 后以 SaaS 方式对外提供服务，必须公开修改后的源代码，这对商业化场景是实质性障碍。
② pyshine.com（2026年7月11日）的技术分析补充了一些具体运维细节：MCP 服务器的速率限制是 300 请求/用户/分钟、最多 20 个并发会话；反向代理需要将 WebSocket 超时配置为 86400s（否则实时同步会断连）；备份恢复接口要求反向代理允许最大 500MB 的请求体。这些细节在 README 中散落各处，该文章做了系统整理，对实际部署有直接参考价值。
两个信源均未发现与原文的实质性反驳，主要是补充了协议风险和运维细节，这些是 README 语境下被淡化的部分。
边界：被过度包装的部分与真实局限
TREK 是一个优秀的自托管工具，但以下几点需要清醒认识：
SQLite 的天花板：单文件数据库对家庭/小团队场景足够，但如果你想做多租户平台或支撑数百名同时在线的用户，SQLite 的并发写性能会成为瓶颈。官方没有提供 PostgreSQL 迁移路径。
它不是推荐引擎，也不是 OTA：TREK 不会告诉你"这个城市什么景点值得去"，不会帮你比价机票，不会和航空公司/酒店 PMS 直接对接。它的定位是"规划和记录工具"，数据来源仍然依赖你自己的输入或 Google Places/OSM。
运维不是零成本：WebSocket 需要反向代理正确配置 upgrade 头；PWA 强制需要 HTTPS；ENCRYPTION_KEY 必须妥善备份（密钥丢失 = 加密数据无法解密）；更新时需要注意卷挂载路径。对完全没有 Linux/Docker 经验的用户，30秒启动承诺更接近"理想状态"。
1-2 人的简单旅行：用 TREK 管理两个人的周末短途是典型的过度设计，Google Maps 的"保存列表"就够了。
个人启发：该如何应用
对于个人开发者/极客用户：如果你已经在跑 Nextcloud 或 Immich，TREK 是非常自然的补充。Journey 模块可以和 Immich 照片直接集成，Atlas 的访问国家统计功能对重度旅行者有实际记录价值。建议先跑 Demo（demo.liketrek.com）体验 15 分钟再决定是否自部署。
对于多人出行的组织者：实时协作 + 费用分摊（Splitwise-style）+ 打包清单分配这三个功能合在一起，解决了团队出行最高频的协调痛点。这比在微信群里拼 Excel 表格要专业得多。
对于 AI 工具重度用户：MCP 集成是值得认真探索的功能。把 TREK 暴露给 Claude/Cursor，让 AI 帮你从邮件 PDF 导入预订信息、自动建行程框架，是真实可用的工作流，而不是演示噱头。
对于有商业化想法的开发者：注意 AGPL-3.0 协议。如果你想基于 TREK 构建 SaaS 产品对外收费，法务层面需要认真评估，或者联系作者获取商业许可。
延伸思考
SQLite 是自托管工具的正确默认选择吗？TREK 的 SQLite 方案降低了部署门槛，但也锁死了水平扩展能力。随着自托管工具功能越来越复杂，"单文件数据库 vs 轻量级 PostgreSQL"的选择将成为这类项目的重要分叉点——Forgejo、Gitea 的多数据库支持模式是否值得 TREK 参考？
MCP 作为权限标准会如何演化？TREK 把 150+ 工具挂在 27 个 OAuth scope 下的设计，本质上是在探索"AI 代理的最小权限原则"应该如何实现。如果这种模式在更多开源项目中被采用，它可能发展成一个事实标准——反过来，Anthropic 的 MCP 规范本身是否足够稳定，会不会因为规范变更让这些投入打水漂？
自托管与隐私的悖论是否被高估了？TREK 的核心卖点之一是"数据留在自己服务器"，但大多数用户的出行数据（目的地、时间）本身并非高度敏感，而自托管服务器的安全运维能力往往弱于 Google/Apple 的专业团队。"自托管 = 更安全"这个等式，在实际场景中究竟在哪些维度成立、在哪些维度是一种安慰剂效应，值得更理性地评估。
📚 参考来源
- GitHub - liketrek/TREK: A self-hosted travel/trip planner with real-time collaboration, interactive maps, PWA support, SSO, budgets, packing lists, and more. · GitHub