umami-software/umami

如果你想要流量、渠道和转化数据，又不想把访客记录交给靠广告变现的第三方，Umami 是一个值得认真考虑的自托管方案。安装文档清楚，界面也不难上手；真正需要想清楚的是自定义程度和访问量规模。

解决什么问题

网站运营者想知道哪些页面、渠道和转化路径真正带来效果，同时不想把访客数据交给第三方，也不想为了基础访问统计去配置 Cookie 弹窗。传统托管分析通常要插入一段回传数据的脚本，数据最终落在别人的后台。Umami 用第一方跟踪脚本和自己的 PostgreSQL 数据库替换这一流程。按项目自己的描述，安装后可以在一个界面里看到页面浏览、渠道、行为、转化和收入报表。

有什么不同

它最明显的选择是把自托管当作正式路径：README 记录了用 Node.js 18.18+ 和 PostgreSQL 从源码运行，也提供官方 Docker 镜像和自带数据库的 compose 文件。这一点重要，因为托管分析厂商的替代方案往往只是关于隐私的承诺；这里数据存在你自己控制的数据库里。Umami 还记录了 MCP 端点，默认关闭，需要设置环境变量开启，AI 客户端可以用单独生成的 API key 查询分析数据。

代价是运维负担。数据库、反向代理或端口配置、更新节奏都要自己负责：源码安装需要拉取、重装依赖并重新构建，Docker 更新则需要拉取新镜像并重建容器。首次构建会建表并创建使用默认密码的 admin 账号，所以加固账号应列入初始安装清单。README 展示了部署方式，但没有给出高流量站点的基准数据，容量规划需要自己测试。

谁值得试

运行内容站、文档站或产品落地页的开发者或小团队比较合适：部署一个容器、加上跟踪脚本，就能拿到渠道和转化报表，基础统计也不依赖单独的同意流程。技术能力较强的个人站长也可以用，但数据库和更新维护可能超过它带来的价值，相比之下更轻量的托管方案未必更差。

不适合完全不想维护、或者只需要超大规模原始事件管道的人。PostgreSQL 依赖和基于重新构建的更新会带来持续工作；一位 Hacker News 评论者（2025-02-17）说，自己为游戏伴侣应用曾大量修改 Umami，原因是缺少功能并有性能问题，这说明自定义、高流量的场景值得尽早做压力测试。Docker compose 是更省事的入口，源码安装则更麻烦。

使用条件与边界

源码安装需要 Node.js 18.18+ 和 PostgreSQL v12.14+，或者改用 Docker 打包路径，并且需要反向代理或调整端口才能对外服务。在配置单独的 64 字符加密密钥之前，无法启用双因素认证，所以安全加固是主动步骤，不是默认状态。MCP 端点默认关闭，开启后 API key 又多了一项需要管理的凭据。

长期成本主要在维护。源码部署每次拉取后都要重新构建，数据库表结构变化也通过构建步骤完成，更新不是点一下就好。README 没有给出备份或迁移方案；在把它当作重要记录来源之前，应先确定 PostgreSQL 数据如何备份。评估时，可以从托管演示和入门文档入手。

HotRepo 点评

HotRepo 的日期记录显示，2026-10-24 为 39,649 星、当日 +43，2026-10-25 为 39,654 星、当日 +45，共两次出现在每日榜单。样本太短，无法判断趋势是上升还是降温，而仓库从 2020 年就已存在。2025-02-13 的 Hacker News 帖子有 348 分和 168 条评论，这只说明讨论量，不是结论。

采纳判断：小规模自托管站点、且看重数据库自主权时值得一试。决定前，请对照你的托管环境确认 项目说明里的 PostgreSQL 版本要求和更新路径。