Umami V3.0.2：一个不到2KB的统计脚本，把Google Analytics的隐私麻烦和Cookie弹窗一起省掉了
现在换掉第三方统计，动机已经不是“免费”了
用百度统计或Google Analytics的人，理由通常很实际：免费、开箱即用。但这两年，继续用它们的代价正在变高。GDPR和CCPA的合规压力让Cookie同意弹窗变成标配，GA4的配置复杂度和数据延迟又让“看一眼流量”这件小事变得不轻松。更关键的是，数据不在自己手里——第三方统计平台调整政策、限制导出或者停止服务，你积累的访问记录说没就没。
Umami解决的就是这个位置上的问题。它是一个MIT协议开源的自托管网站分析平台，跟踪脚本不到2KB，默认不写Cookie、不跨站追踪、不收集个人身份信息，部署在自己的服务器上，数据落在自己控制的PostgreSQL里。彩虹源码网（www.yuanmaz.com）这次整理的V3.0.2，是Umami进入v3大版本后的一个稳定小版本，下面不讲功能清单，讲清楚V3到底变了什么、部署时哪些坑和以前不一样。
2KB的脚本，和“不拖慢网站”之间的因果关系
Umami的跟踪脚本官方标注是“under 2KB”。这个体积意味着什么：把它加到页面里，对LCP和整体加载时间的影响几乎可以忽略。对比GA4的gtag.js，Umami在性能层面的优势不是“优化了一点”，而是“不在同一个量级”。对于Core Web Vitals本身就不太宽裕的站点，换统计工具本身就可能带来可测量的性能改善。
无Cookie不只是一个隐私口号，它直接省掉了同意弹窗
Umami默认不写Cookie。这意味着在大多数司法辖区，你不需要为它挂一个Cookie同意横幅。Cookie弹窗对转化率的伤害是实打实的，一个自托管统计工具如果能让你把弹窗去掉，这本身就是收益。GDPR和CCPA合规在Umami这里是默认状态，不是需要额外配置的选项。
V3最大的架构变化：MySQL没了，只剩PostgreSQL
这是升级到V3之前必须知道的一件事。Umami v3不再支持MySQL作为数据库选项，只支持PostgreSQL。v2时代MySQL和PostgreSQL并存的局面结束了。
对全新部署的人来说，这反而简化了选择
如果你是从零搭一个Umami，V3的数据库决策没有悬念：PostgreSQL。Docker Compose的官方示例直接捆绑了postgres:15-alpine，DATABASE_URL指向内置的db服务。源码安装的要求同样明确：Node.js 18.18以上、PostgreSQL 12.14以上、pnpm作为包管理器。
对v2老用户来说，迁移是必须跨过的一道坎
已经在用v2 + MySQL的站点，不能直接原地升级到V3然后指望数据库自动切换。Umami官方提供了一份从MySQL迁移到PostgreSQL的指南，但迁移不是点一下按钮的事，涉及数据导出、格式转换和导入验证。如果你的站点数据量不大，更干净的做法可能是V3新装一套PostgreSQL，旧数据按需归档，而不是强行迁移。
PostgreSQL版本和资源要求，比想象中低
Docker Compose的官方示例用的是postgres:15-alpine，最低要求512MB内存和1GB磁盘空间。源码安装要求PostgreSQL 12.14以上。对于个人博客或中小站点，一台1核2G的VPS跑Umami + PostgreSQL绰绰有余。Umami本身不是资源密集型应用，它的轻量定位从脚本一直贯穿到后端。
两条部署路线，选哪条取决于你后面要不要改代码
路线一：Docker Compose，五分钟能跑起来的那种
官方推荐Docker作为安装方式，Docker Compose是最快的路径。核心步骤是把官方仓库的docker-compose.yml拉下来，或者自己写一份，docker compose up -d启动，docker compose ps确认umami和db两个容器都是healthy状态，浏览器访问IP:3000，默认账号admin、密码umami，登录后第一件事改密码。
唯一需要手动改的地方是APP_SECRET。官方明确要求部署到生产环境前把它换成一个随机字符串，可以用openssl rand -base64 32生成。不改也能跑，但安全性上等于把会话密钥公开了。
路线二：源码安装，适合需要定制或二开的人
源码安装的硬性条件是Node.js 18.18+、PostgreSQL 12.14+、pnpm、Git。流程是clone仓库、checkout到指定版本、pnpm install、写.env（DATABASE_URL和APP_SECRET）、pnpm run build。build这一步会自动做三件事：生成Prisma client、跑数据库迁移、建默认admin账号。build完成后pnpm start启动，默认监听3000端口。
源码安装的价值不在“更快”，在于你能看到Next.js、React和Prisma的版本，能在本地改代码、调配置、做二次开发。代价是升级需要手动拉代码重新build，不像Docker那样换镜像标签就行。
宝塔用户的反向代理配置，端口和路径别搞混
无论走Docker还是源码，Umami默认都在127.0.0.1:3000上提供服务。宝塔面板的配置路径很直接：新建一个纯静态站点，进入“反向代理”，目标URL填http://127.0.0.1:3000，保存后绑定域名并申请SSL证书。反向代理不配，就只能用IP:3000访问，既不方便也不安全。配完反代后用域名访问，确认登录页能打开、静态资源加载正常，再继续后面的站点添加。
装完之后，真正要配的是“让数据进来”
添加网站 → 拿跟踪代码 → 验证第一条数据
登录后第一件事是添加网站，Umami会生成一段带data-website-id的script标签。把这段代码放到目标站点的
或里，然后在另一个浏览器（或无痕窗口）打开目标站点，回到Umami看实时访客是否出现。没有实时数据先检查两件事：跟踪代码里的网站ID和目标站点是否匹配；Umami的反向代理域名是否可公网访问（如果统计端和目标站在同一台服务器上，用内网地址可能被浏览器拦截）。自定义事件不需要SDK，加一个HTML属性就行
Umami V3的事件追踪不需要引入额外的SDK。在任意HTML元素上加data-umami-event="事件名"，点击、表单提交或下载就会自动记录。自定义属性用data-umami-event-*的格式附加。这对于不想写JavaScript、只想标记按钮点击或表单提交的场景，比GA4的事件配置轻得多。
V3新增的Links和Pixels，解决的是“统计不到的地方”
V3引入了两个新的追踪元素：Links是短链接，可以统计某个链接被点击了多少次、下载链接被点击了多少次；Pixels是嵌入在外部页面或邮件里的不可见图片，用于统计那些你没法安装跟踪脚本的地方的访问，比如邮件打开率或第三方页面上的曝光。这两个功能各有独立的统计页面，和网站统计平级。它们不是必需品，但如果你的分发渠道包含邮件、外部合作页面或下载链接，V3在这块的覆盖比v2完整。
部署时容易踩的三个坑
坑一：以为V3还能用MySQL
v2升级上来的用户最容易在这里卡住。V3的代码里已经没有MySQL的适配了，.env里写mysql://的连接串不会“降级兼容”，只会启动失败。全新部署直接用PostgreSQL，v2迁移先看官方迁移指南。
坑二：APP_SECRET用了示例值
replace-me-with-a-random-string跑在本地测试没问题，放到公网就是风险。Docker部署时改docker-compose.yml里的环境变量，源码部署时改.env，改完重启服务。这不是“建议”，是官方在文档里用“Important”标出来的必做项。
坑三：反向代理配了，但WebSocket或子路径出问题
Umami的实时数据依赖正常的HTTP连接，一般反向代理配好就能用。但如果站点部署在子目录（比如/umami）而不是独立域名，静态资源路径和API路由可能需要额外调整。推荐直接用独立域名或子域名做反代，省掉子路径带来的路径重写问题。
包里有什么，谁适合用这套东西
🔥永久赞助9.9(高速下载/无广告/无转存)
✅网盘下载(下载限速/需要转存/有广告)
下载内容说明
Umami是开源项目，源码和Docker镜像都是公开的，不存在“去授权版”或“破解版”的概念。彩虹源码网整理的V3.0.2相关资源，核心是可用的源码包、Docker Compose配置模板和部署说明。不包含托管服务、域名、SSL证书和服务器本身。如果你不想自己维护服务器，Umami官方也提供Cloud托管方案，免费额度覆盖3个网站，对个人站点够用。
适合谁，以及一个务实的判断
适合对隐私合规有要求、不想挂Cookie弹窗、希望数据自主可控的站长和开发者。适合已经在用VPS或NAS、有基本Docker或Node.js操作能力的人。如果你只需要“看看PV/UV”且完全不介意数据放在第三方，继续用现有工具也合理；但如果你已经在为Cookie同意弹窗的转化率损失头疼，或者受够了GA4的配置复杂度，Umami V3在“轻量、合规、自托管”这三个维度上的组合，目前是开源方案里比较完整的一个。
免责声明：本文由彩虹源码网（www.yuanmaz.com）整理发布，仅供开源工具学习和合法站点统计部署参考。Umami采用MIT许可证，使用和分发须遵守其许可证条款。自托管统计涉及服务器运维和数据安全，生产环境部署前请在测试环境验证，并妥善保管APP_SECRET和数据库凭据。本文不构成对任何特定部署环境安全性或合规性的保证。
觉得内容不错？我要
