网站统计方案横向对比

本站到今天为止一个统计脚本都没装，实在是难以抉择使用哪个，一个是必须内存占用低，另外需要全球可达，还需要精细化统计，目前还没有能满足我需求的。趁这次把候选名单里的方案全部拆开过一遍。

这些工具的差别不在功能列表，而在「数据在哪儿被采到」。采集位置一旦定了，可达性、拦截、加载开销、颗粒度四个维度就基本被决定了，剩下的都是包装。

二、一条主线：数据在哪儿被采到

四个采集位置，几乎解释了后面所有差异。

这里有个反直觉的点：「自托管」和「拦不住」是两回事。自托管的 Umami 依然是浏览器里的一段 JS，照样在拦截规则的射程内。真正拦不住的只有第二、三行——数据根本没经过访客的浏览器去请求第三方。

三、九个方案逐个过

3.1 GA4（Google Analytics 4）

行业默认值，功能上限最高：事件模型可以把任何动作建模成 event，配合自定义维度、受众、归因、跨端（Web + App）打通。免费版的硬限制查得到：每事件 25 个参数、30 个关键事件、每媒体资源 50 个事件级自定义维度、数据最长保留 14 个月、探索报告每次查询 1000 万事件的抽样上限。

三个代价很实在：

1、最大的脚本。实测 gtag.js 压缩后 145 KB、解压 409 KB，是本文所有方案里最重的，比第二名还大 80%。

2、最招拦截。EasyPrivacy 里 ||googletagmanager.com^ 是无条件整域拦截，不带任何例外条件。

3、大陆能采不能看。实测采集端点 www.google-analytics.com/g/collect 返回 204、脚本域也通，但后台 analytics.google.com 五次尝试全部失败。等于数据在往上传，你自己却要翻墙才看得到。

3.2 Umami（自托管）

MIT，TypeScript，3.8 万 star，现在是自托管统计里最主流的一个。官方要求：Node.js 18.18+ 与 PostgreSQL 12.14+（新版本已不再支持 MySQL），Docker Compose 一条命令能起。

颗粒度覆盖页面、来源、设备、浏览器、系统、国家、UTM，加上自定义事件与事件属性；文档里还列了目标、漏斗、用户路径（Journey）、留存、收入归因，以及会话回放与热图。脚本实测压缩后 2.3 KB，非常轻。

代价是它是这批里常驻服务最重的之一：一个 Next.js/Node 进程加一个 PostgreSQL，一台 1 GB 内存的小机器跑起来会紧张。

3.3 Umami Cloud（托管版）

官方托管，省掉数据库和升级。截至 2026-08-19 的档位：

两条要注意：会话回放与热图在 Business 档才有；官方 FAQ 明说云版比自托管多出来的是邮件报表与 streaming API。免费档 1 个站点、6 个月保留，对个人博客刚好够，但要留意超额是继续采集然后按量计费，不是停掉。

3.4 Plausible（自托管 CE + 云版）

Elixir 写的，2.9 万 star，主程序 AGPL-3.0，部署仓库 community-edition 是 MIT。脚本实测压缩后 1.3 KB，全场最小。

指标设计是这批里最考究的：独立访客、会话、跳出率、访问时长、单页停留时长、滚动深度、退出率、来源与 Channel 分组、UTM 全套、国家/地区/城市、目标与转化率、漏斗、用户路径、自定义属性。不用 cookie，不需要 cookie 横幅。

自托管的门槛在依赖：PostgreSQL 加 ClickHouse，官方要求 CPU 支持 SSE 4.2 或 NEON 指令集（ClickHouse 的硬要求），推荐至少 2 GB 内存。这已经不是「顺手在博客服务器上多起一个服务」的量级了。云版没有免费档，只有试用。

3.5 Cloudflare Web Analytics

免费，所有套餐可用。原理是一段 RUM beacon，用 Performance API 采数据；站点如果已经过 Cloudflare 代理，可以在边缘自动注入，连改模板都省了。

它的独门优势是性能维度：LCP、CLS、INP、TTFB、FCP 全套 Core Web Vitals，外加导航计时、资源计时、Server-Timing。可筛选的维度是国家、Host、路径、来源、设备类型、浏览器、操作系统、站点、导航类型（能区分「走没走缓存」这种别处没有的信息），并且带一个 Exclude Bots 开关。

官方明确写了不写 cookie、不碰 localStorage、IP 在最近的数据中心就丢弃。限制也清楚：未走 Cloudflare 代理的站点最多 10 个，免费档规则数为 0（即整站注入，不能按路径开关）。

不足是没有自定义事件、没有会话概念——它是「网页表现监测」而不是「用户行为分析」。脚本 11 KB，比同类重，因为里面塞了 Google 的 web-vitals 库。

3.6 GoAccess

彻底的另一条路：它不在页面上放任何东西，直接读 nginx / Apache / Caddy / CloudFront 的访问日志。C 写的老牌工具，MIT，唯一依赖是 ncurses，可以在终端里实时刷，也能生成一个自包含的 HTML 面板。

它的三条优势别的方案给不了：

1、零加载开销、零拦截——访客那边一个字节都没多下。装 uBO 也好、关 JS 也好、curl 也好，全都统计得到。

2、能看到别人看不到的东西：状态码分布、慢请求、带宽消耗、爬虫、虚拟主机、ASN 归属。查故障和查恶意流量时，这些比 PV 有用得多。

3、历史数据是现成的——日志一直在，装上当天就能回看过去几个月。

代价同样明确：拿不到任何前端信息（屏幕、停留、滚动、点击一概没有），而且默认统计到的是「请求」不是「人」——爬虫、预取、CDN 回源全在里面，需要自己过滤。同一出口 IP 后面几个人也分不开。

3.7 Counterscale

MIT，跑在 Cloudflare Workers + Workers Analytics Engine 上的自部署统计，npx @counterscale/cli install 一条命令装完。作者的说法是 Cloudflare 免费额度大约能撑到每天 10 万次命中。

它是「自托管」里唯一不需要服务器的：没有数据库、没有常驻进程、没有升级维护，成本趋近于零。脚本实测压缩后 1.9 KB，另外提供服务端模块（@counterscale/tracker/server），可以完全绕开浏览器上报。

顺带一个意外发现：它是全场唯一在三大过滤规则列表里查不到任何规则的方案（见 4.3）。用的人少是原因之一，但「部署在自己的域名上」这个形态本身也确实难被规则化。

它的代价集中在四处：

1、默认部署地址在大陆完全不通。安装脚本给的是 xxx.workers.dev，而 workers.dev 整个域在大陆被 DNS 污染——实测解析到 108.160.172.204（Dropbox 段）和 199.59.149.205（Twitter 段），六次连接全部超时。必须给 Worker 绑一个自己的自定义域名（README 有这一节），落到 Cloudflare 的正常 anycast IP 上才通。同一时刻实测自有 CF 域名 2.9 秒正常返回，所以问题只在 workers.dev 这个域，不在 Cloudflare。

2、只有 90 天。这是 Analytics Engine 的硬保留期，README 写得很直白：面板「只能显示最近 90 天」。R2 里那份 Apache Arrow 归档是冷存，面板查不到，要看得自己把文件拉下来分析。

3、维度比想象中窄。读 schema.ts 的列映射：host、userAgent、path、country、referrer、browserName、browserVersion、deviceModel、deviceType、UTM 五件套。没有操作系统、没有屏幕尺寸、没有语言，地理只到国家。也没有自定义事件——数据点结构是写死的，只有 pageview。

4、独立访客是用 HTTP 缓存头凑出来的。collect.ts 靠 If-Modified-Since / Last-Modified 做无 cookie 计数，命中次数编码在秒位上且封顶 3（1 = 新访客、2 = 反跳出、3 = 正常）。于是「独立访客」只在当天成立，跨天必然重新计数；跳出率是这套编码推出来的近似值，不是真的会话分析。访客清缓存或用隐私模式，计数就偏。

另外它不做任何机器人过滤（collect.ts 里没有 bot 判断，CF Web Analytics 那个 Exclude Bots 开关它没有），好在上报要执行 JS，多数爬虫进不来。

3.8 GoatCounter（自托管）

Go 写的单个静态二进制，EUPL-1.2（作者改过 Compatible Licenses 附录的版本），数据库用 SQLite 就够，goatcounter serve 一条命令起服务，连 TLS 与 ACME 自动签证书都内置了。这是本文里部署最轻的自托管方案，没有之一。

它真正的过人之处是三种采集方式都支持：JS 脚本、无 JS 的图片像素、后端中间件调 API，外加从 nginx/Apache/Caddy/CloudFront 日志导入。也就是说被拦截器挡住的那部分，可以用日志导入补回来——这个组合别家没有。

维度是浏览器、系统、屏幕尺寸、地理位置、来源、campaign，用不可还原的哈希在不写 cookie 的前提下识别独立访问。官方自称脚本「只增加约 3.5 KB」，实测压缩后 3.3 KB，说法诚实。

3.9 GoatCounter 托管版（goatcounter.com）

同一个程序的官方托管，「对合理的公开用途免费」，靠 GitHub Sponsors 捐助维持，官方原话是跑个人网站或中小企业没问题、每天几百万 PV 就别来了。对个人博客这是全场性价比最高的选项之一。

但对大陆站点它基本不可用。实测：主站 www.goatcounter.com 通（1–3 秒），脚本 CDN gc.zgo.at 五次全部超时。查 DNS 就明白了：

$ nslookup gc.zgo.at            # 用 8.8.8.8
Addresses:  2a03:2880:f10a:83:face:b00c:0:25de     ← Facebook 的地址段
            104.244.46.52                          ← Twitter 的地址段

解析结果被投毒到了社交平台的 IP 上，TCP 必然握不上手。后台能看，脚本加载不了，大陆访客一个都统计不到。 自托管版不受影响，这是托管版独有的问题。

3.10 Microsoft Clarity

它和上面所有工具不是一个品类：不是流量统计，是行为分析。官方支持的功能是会话录制、热图、事件与漏斗、Copilot 摘要。官方文档写得很直白：「Clarity is a free service forever」，没有付费档要升。

想知道「读者读到第几屏关掉的」「哪个按钮被反复点却没反应」，只有这类工具能回答，前面九个都不行。

代价是它是隐私尺度最大的一个——录制的是访客的真实操作。脚本压缩后 25 KB，且录制期间持续上传。EasyPrivacy 里 ||clarity.ms^ 是整域拦截。另外官方明确要求：不得用于面向 18 岁以下用户的网站与应用。

好消息是它的可达性最好：大陆实测脚本 0.6–0.8 秒、后台 3 秒左右，全部通过，是所有需要登录后台的方案里表现最好的。

3.11 PostHog

产品分析全家桶：事件、漏斗、留存、路径、群组、特性开关、A/B 测试、会话回放、错误跟踪。对 SaaS 产品是好东西，对博客是杀鸡用牛刀。

自托管这条路官方自己在劝退，文档原话是云版「对绝大多数用户体验好得多」，并且列了硬要求：4 vCPU、16 GB 内存、30 GB+ 存储；不提供任何技术支持；所有付费功能仅限云版；超过每月 30 万事件或 1000 条录像就需要专业运维能力。

脚本 array.js 实测压缩后 80 KB，仅次于 GA4，而且开会话回放还要再加载 recorder。大陆实测：脚本域通（3.7–5.9 秒），后台 us.posthog.com 通但慢到接近不可用——单次登录页要下 50 万字节，三次里两次在 20 秒内没下完。

四、三组实测数据

以下三组是本文唯一的原创数据，测于 2026-08-19。可达性那一栏是在中国大陆家庭宽带上直连、不走任何代理测的，换运营商换时段结果会变，只能当参考不能当结论。

4.1 脚本体积（实测）

用 curl 带 --compressed 直接拉线上文件测的，「解压后」是原始字节数。

GA4 一个脚本，等于 111 个 Plausible。 这个差距在手机弱网上是能被感知到的。

4.2 大陆可达性（实测）

两个值得记住的结果：GA4 是「采得到看不到」，GoatCounter 托管版是「看得到采不到」，方向正好相反，但对大陆站点都是致命的。

Counterscale 那两行是同一套代码的两种部署：workers.dev 这个域整个被污染（解析到 Dropbox 和 Twitter 的地址段），绑上自己的域名之后落到 Cloudflare 正常的 anycast IP，立刻就通了。用 Cloudflare 的东西，别用它送的那个二级域名。

4.3 拦截规则（实证）

把三份主流规则文件抓下来直接搜：EasyPrivacy（uBO 默认订阅）、uBO 自家的 privacy 列表、AdGuard 的追踪保护列表。

真正值得警惕的是自托管也跑不掉。 规则里有一批通配写法，专打「按默认方式部署」的自建实例：

||umami.*/script.js|$script          ← 任何 umami. 开头的域名下的 script.js
://plausible.*/js/script.            ← 自建 Plausible 的默认脚本路径
://plausible.*/api/event|            ← 连上报接口一起拦
/plausible/*.js$script               ← 反代到 /plausible/ 路径同样命中
/posthog/ingest/*                    ← PostHog 的常见反代路径

通配之外还有逐个点名。把三份列表合起来去重，数了一下被单独写进规则的自建实例域名：

plausible.safing.io、umami.vidfast.pro、posthog.tarnkappe.info 这类条目一条条躺在文件里。所以「我自建就没人拦得到」是幻觉——只要按默认命名部署、站点又有点流量，被人报上去写进规则只是时间问题。

五、五个维度的总账

服务端开销这一栏是按官方要求和组件栈给的量级，不是压测数据——Plausible 的 2 GB、PostHog 的 16 GB 是官方白纸黑字写的；GoAccess、GoatCounter 的「极低」依据是它们的组件构成（一个 C 二进制、一个 Go 二进制加 SQLite）；Umami 的量级来自「Node 进程加一个 PostgreSQL」这个事实。真要一个准确数字，得在自己机器上跑一周看 RSS。

六、怎么选

按最在意的那一条走：

1、要一个诚实的访客数，不想被拦，不想加载任何东西 → GoAccess。日志已经在那儿了，装上就能回看历史，代价是拿不到任何前端信息。

2、既要前端维度、又不想被拦漏太多 → GoatCounter 自托管：JS 脚本正常采，再定期把 nginx 日志导进去补上被拦掉的部分。这是唯一能把两条路合并的方案。

3、不想维护服务器，站点已在 Cloudflare 后面 → Cloudflare Web Analytics。免费、边缘注入不用改模板，还白送 Core Web Vitals。

4、想要漂亮面板和事件分析，愿意养一个服务 → Umami 自托管（Node + PostgreSQL），或者懒一点直接上 Umami Cloud 免费档。

5、一台服务器都不想有，也不想付钱 → Counterscale，跑在 Workers 上成本趋近于零，代价是数据只留 90 天、维度基础。

6、想知道读者到底怎么读的 → Clarity，和上面任意一个并存。它回答的是别人回答不了的问题。

7、做的是产品不是博客 → PostHog 云版，自托管那 16 GB 的要求不值得。

8、必须用 GA4（要接广告，或者甲方要求）→ 接受它 145 KB 的体积和必被拦的现实，并且准备好一条能看后台的路。