Liwan 1.8 介绍与选型指南
Liwan 自托管隐私优先 Web 分析全景介绍：Rust 单二进制架构、隐私采集白名单、与 Plausible/Umami/Offen/Shynet 的量化选型对比与适用场景建议。
Liwan 1.8 介绍与选型指南
在自建网站的流量统计这一细分领域里，绝大多数自托管方案都会把「部署复杂度」转嫁给使用者：要么需要一个独立的 PostgreSQL，要么再配一个 ClickHouse 或 Redis。Liwan（官网 liwan.dev）是这一格局里少见的例外——它用 Rust 写成，把 Web 服务、看板前端、事件入库、报表查询全部塞进一个静态链接的单二进制文件里，数据库直接内嵌，官方口号是 "Self-hosted, privacy-first web analytics"（自托管、隐私优先的 Web 分析）。本文基于 2026-10-30 从 liwan.dev 官网、GitHub Releases 订阅源（releases.atom）与 shields.io 徽章接口获取的公开资料，对 Liwan 的定位、特性、隐私模型做一次完整梳理，并与 Plausible、Umami、Offen、Shynet 四款同类自托管分析工具做量化对比，帮助你判断它是否适合你的服务器。
💡 技术拓展：单二进制（single binary） 与传统「应用 + 独立数据库」两种部署形态的差异值得展开。单二进制指程序把 HTTP 服务、静态资源、存储引擎全部编译进一个可执行文件，升级时只需替换一个文件；传统形态则要求先维护数据库服务再做应用部署，优点是数据库可独立扩容、多应用共享。Liwan、Offen 属于前者，Plausible（依赖 PostgreSQL + ClickHouse）、Shynet（依赖 PostgreSQL）属于后者，Umami 介于两者之间（Node 应用 + 独立关系库）。选型的第一分水岭往往就在这里：你希望「少管一个服务」还是「数据库要能横向扩展」。
一、项目概况与版本信息
1.1 基本信息一览
以下信息均从公开渠道核实（来源与查询日期标注在每条之后）：
| 项目 | 内容 | 来源（查询日期 2026-10-30） |
|---|---|---|
| 产品定位 | 自托管、隐私优先的 Web 分析 | liwan.dev 首页 meta description |
| 开发语言 | Rust（服务端）+ JavaScript（前端与追踪脚本） | liwan.dev 首页、官方文档 |
| 开源许可 | Apache License 2.0 | liwan.dev 首页 tagline "Fully open source, licensed under the Apache License 2.0" |
| 源码仓库 | github.com/explodingcamera/liwan | liwan.dev 首页页脚 GitHub 链接 |
| 当前版本 | v1.8.2（2026-10-29 发布） | GitHub Releases 订阅源 releases.atom |
| 社区热度 | GitHub Stars 219 | shields.io 星数徽章接口 |
| 作者 | Henry Gressmann（个人开源项目） | liwan.dev 页脚 imprint 指向 henrygressmann.de |
| 默认端口 | 9042 | liwan.dev 首页 Docker 示例命令 |
需要说明的是：Liwan 是个人维护的开源项目，社区规模（219 Stars）远小于 Plausible、Umami 这类明星项目，这一点在选型时应纳入考量——它换来的是极高的代码可读性与极简的部署面。
1.2 版本节奏
从 releases.atom 的发布记录看，Liwan 的迭代相当活跃（查询日期 2026-10-30）：
- v1.8.2（2026-10-29）：修复 MaxMind 数据库自动更新在 metadata 含数字时间戳时失败的问题；
- v1.8.1（2026-10-23）：更新 TLS 根证书与 zip 依赖的安全维护版本；
- v1.8.0（2026-10-17）：一个大版本，包含两项破坏性变更（私有项目的用户级直授权被团队机制取代；追踪器 npm 包从
liwan-tracker更名为@liwan.dev/tracker），并新增自定义事件、自定义属性、带鉴权的批量事件摄入端点、API Key 管理界面、可配置会话时长、看板图小时/天/周/月四种聚合粒度、拖拽选择自定义日期区间等大量功能。
一个以天为单位滚动发版、并且敢在 minor 版本里做破坏性重构的项目，说明它处于快速成长期而非维护期。
二、核心特性
2.1 官方宣传的六大特性（liwan.dev 首页）
- 看懂你的流量：实时更新的看板，默认过滤机器人流量，展示热门页面、流量来源与趋势变化；
- 易于自托管：以单二进制或 Docker 容器运行，看板与数据库内建，无需额外服务；
- 隐私优先：不使用追踪 Cookie，不做跨站追踪，不记录原始 IP 地址，数据全部留在你自己的服务器上；
- 按需采集：位置精度（国家+城市/仅国家/不采集）、广告活动归因（UTM）、访客分组、会话指标（跳出率、停留时长、入口/出口页）均可独立开关；
- 轻量埋点：一行
<script>标签接入浏览器端追踪，也可以完全由服务端发事件；适配任意框架或 CMS； - 单点登录：支持 Google Workspace、Microsoft Entra ID 以及 Keycloak、Dex 等任意 OpenID Connect 提供商管理账号。
2.2 隐私模型（来源：liwan.dev/collected-data/）
Liwan 的隐私设计有明确的「白名单」气质，官网专门用一页说明它采集什么、不采集什么：
- 浏览器端发送：页面 URL（剔除片段与非归因参数）、来源站 Referrer、UTM 归因参数、粗粒度屏幕宽度分档（如 SM/MD/XL）、横竖屏、事件名（默认 pageview）、可选的自定义属性、页面退出信号；
- 服务端推导：访客分组 ID、浏览器/平台家族（不保存完整版本号）、设备类型、国家与城市（来自 MaxMind 或可信代理头）、会话时长；
- 明确不存：原始 IP 地址、访客追踪 Cookie、跨站访客标识、完整 Referrer 路径、普通页面的查询串与片段。
其中访客分组提供了 5 种模式，这是同类产品里少见的「把隐私粒度做成开关」的设计（来源：liwan.dev/collected-data/）：
| 模式 | 行为 |
|---|---|
| Accurate（精确） | 对完整 IP + User-Agent + 轮转盐值 + 实体 ID 做哈希，原始输入不落盘 |
| Random per request（每请求随机） | 每个事件生成互不相关的访客 ID，完全不可跨请求关联 |
| Network standard（网络-标准） | 哈希 IPv4 /24 或 IPv6 /56 网络前缀 |
| Network balanced（网络-均衡） | 哈希 IPv4 /28 或 IPv6 /64 网络前缀 |
| Network accurate（网络-精确） | 哈希完整 IP（不含 User-Agent） |
分组盐值每天在配置的时刻（默认凌晨 4 点）轮转一次，访客分组因此不会跨天持久化。
💡 技术拓展：访客去重的三种流派。第一种是存明文 IP（传统日志分析，如早期 AWStats），法律风险最高；第二种是存 IP 的单向哈希（Shynet 采用），库泄露时仍可被彩虹表式穷举攻击；第三种是 Liwan/Plausible 这类「盐值哈希 + 定期轮转」，连「同一访客跨天是否回访」都无法回答，以此换取更强的匿名性。代价是跳出率、回访率等指标天然只能做近似统计，这是所有隐私优先产品的共同取舍，不是实现缺陷。
2.3 v1.8 带来的分析能力扩展（来源：releases.atom v1.8.0 条目）
- 自定义事件（custom events）与自定义属性（custom properties），属性支持字符串/数字/布尔，单事件最多 30 个属性、键 64 字符、值 255 字符（来源：liwan.dev/guides/tracking/）；
- 带鉴权的批量事件摄入端点，配合 v1.8 新增的 API Key 管理界面，可以把服务端日志、后端业务事件灌入 Liwan；
- 看板图支持小时/天/周/月四种区间粒度与拖拽自选日期；
- 跳出率与平均时长支持配置最小样本数（
[limits]段），避免低样本噪声。
三、部署形态与技术栈
3.1 两种官方运行形态
liwan.dev 首页给出的两条路线：
- 单二进制：从 GitHub Releases 下载对应平台的预编译包。官方提供 Linux x86_64、Linux ARM64 与 macOS ARM64 三种构建，Linux 版用 musl libc 静态链接，「应该能在大多数 Linux 发行版上直接运行」（来源：liwan.dev/install/binary/）；
- Docker 镜像：官方镜像
ghcr.io/explodingcamera/liwan:1.8，首页给出的示例命令为docker run -p 9042:9042 -v liwan-data:/data -e LIWAN_BASE_URL=http://localhost:9042 ghcr.io/explodingcamera/liwan:1.8（来源：liwan.dev 首页，2026-10-30）。
3.2 内嵌存储
Liwan 的事件数据由内嵌的 DuckDB 列式数据库管理，配置面提供 duckdb.memory_limit 与 duckdb.threads 两个资源旋钮（来源：liwan.dev/reference/configuration/）；账号、项目、实体等元数据则存储在独立的 SQLite 文件中。两者都落在同一个数据目录里，备份就是备份目录。官方还提供了 DuckDB 调优指引页（liwan.dev/guides/duckdb/）。
💡 技术拓展：为什么 Web 分析场景偏爱 DuckDB 这样的列式 OLAP 引擎。流量报表的典型查询是「按天聚合、按维度切片、全表扫描」，这类负载下列式存储只读取涉及的列，压缩率高、扫描快；而行式 OLTP 库（MySQL/PostgreSQL）在这种大范围聚合上容易吃满 IO。Plausible 直接采用 ClickHouse，Liwan 内嵌 DuckDB，思路同源：把 OLAP 引擎做进进程里，省掉独立数据库服务。DuckDB 与 ClickHouse 的差异主要在并发模型与集群能力——前者面向嵌入式单机场景，后者面向分布式集群，对自托管中小流量站点而言前者反而更省心。
3.3 生态与集成
- 追踪脚本由 Liwan 服务端自身托管（
/script.js），版本永远与服务器一致；也可改用 npm 包@liwan.dev/tracker发自定义事件（来源：liwan.dev/guides/tracking/）； - 官方文档提供反向代理（Caddy 示例）、GeoIP（MaxMind 接入）、Adblocker 场景、Cookie 横幅、systemd/OpenRC 服务化等指南页；
- 数据可通过官方 DuckDB 指南直接用 SQL 对事件库做深度分析（liwan.dev/guides/duckdb/）。
四、量化选型对比
下表对五款可自托管的隐私向 Web 分析工具做横向对比。Liwan 列的数据来自 liwan.dev 官网与 GitHub Releases 订阅源（查询日期 2026-10-30）；其余四款来自各自官网与 GitHub 仓库的公开资料（查询日期 2026-10-30）。个别定性描述以官网自述为准，请在采购决策前以官方文档复核。
| 维度 | Liwan | Plausible CE | Umami | Offen | Shynet |
|---|---|---|---|---|---|
| 开发语言 | Rust | Elixir（+ ClojureScript） | TypeScript / Node.js（Next.js） | Go | Python（Django） |
| 开源许可 | Apache-2.0 | AGPL-3.0（CE 版） | MIT | Apache-2.0 | Apache-2.0 |
| 部署形态 | 单二进制 / 官方镜像 | Docker Compose 为主 | Node 服务 / Docker | 单二进制 / Docker | Django 应用 / Docker |
| 外部依赖 | 无（内嵌 DuckDB + SQLite） | PostgreSQL + ClickHouse | PostgreSQL 或 MySQL | 无（内嵌存储） | PostgreSQL + Redis |
| 存储引擎 | 事件入列式 DuckDB，元数据入 SQLite | ClickHouse（事件）+ PostgreSQL（元数据） | 关系数据库 | 内嵌键值库 | 关系数据库 |
| 隐私模型 | 不存原始 IP；5 档访客分组哈希；盐值每日轮转；采集项逐项可关 | 不用 Cookie，IP 哈希后存储 | 不用 Cookie，可配 IP 哈希 | 终端用户可查看并删除自己的数据，双重 opt-in | 不用 Cookie，IP 哈希存储 |
| 自定义事件 | v1.8 起支持（含属性与批量摄入） | 支持（部分为云版功能） | 支持 | 支持 | 支持（custom goals） |
| 单点登录 | Google Workspace / Entra ID / OIDC | 商业云版支持，CE 版有限 | 不内置 | 不内置 | 不内置 |
| 官方镜像 | ghcr.io/explodingcamera/liwan | plausible/analytics | umami/umami | offen/offen | milesmcc/shynet |
| 运维面 | 一个二进制 + 一个数据目录 | 多容器栈 | Node + 独立数据库 | 单二进制 + 数据目录 | Django + 数据库 + Redis |
从表中可以读出清晰的三档：
- 零外部依赖档：Liwan、Offen——单文件起步，适合个人站长与小型团队；
- 轻依赖档：Umami——一个 Node 进程加一个关系库，适合已有 MySQL/PostgreSQL 运维经验的团队；
- 重依赖档：Plausible CE、Shynet——能力更全面或历史更久，但要用多容器/多服务栈换取。
五、适用场景与选型建议
5.1 Liwan 的甜点区
- 个人博客、作品集、中小型产品官网：单二进制 + 内嵌存储意味着从「下载」到「看到第一个 pageview」可能只需要十分钟，且日常维护只有「升级一个文件」一件事；
- 对隐私合规有硬要求的站点：不存原始 IP、不使用 Cookie、采集项可逐项关闭并支持对历史数据做裁剪（官方提供 prune 工具），这些设计让隐私声明非常容易写；
- 需要把分析数据当数据库用的团队：DuckDB 文件可以直接用 SQL 查询，官方还给了调优指南；
- 追求部署极简的服务器：无外部数据库意味着更少的攻击面、更少的备份对象、更少的版本矩阵。
5.2 何时不要选 Liwan
- 需要大规模团队协作与成熟的权限体系：Liwan 的团队功能在 1.8 才完成从「用户直授」到「团队制」的迁移，成熟度不及 Plausible 的商业版；
- 需要超大规模流量与集群扩展：单机 DuckDB 没有横向扩展故事，亿级事件量应考虑 ClickHouse 系方案；
- 需要官方 SLA 或托管服务：Liwan 没有商业托管，出问题要靠社区（当前主要是作者本人）响应；
- 项目成熟度敏感的场景：219 Stars 的个人项目，选型时应做好「跟随升级、偶发破坏性变更」的心理准备（v1.8.0 即含两处 breaking change）。
5.3 与本站其他方案的关系
如果你希望做更宽的横向对比，本站还有以下同类方案的完整系列，建议配合阅读：
- 《Plausible 介绍与选型指南》——Elixir + ClickHouse 路线的代表，功能最接近 Google Analytics 的隐私替代品，部署篇见《Plausible Docker Compose 部署指南》；
- 《Umami 介绍与选型指南》——MIT 许可的 Node.js 方案，生态与文档成熟度最高，部署篇见《Umami Docker Compose 部署指南》；
- 《Offen 介绍与选型指南》——Go 语言单二进制方案，Liwan 在「零外部依赖」形态上最直接的对照物，部署篇见《Ubuntu 22.04 安装 Offen 1.4.2 指南》，其运维细节另见《Offen 1.4.2 常用 CLI 命令与工具详解》。
而如果你已经决定使用 Liwan，建议按这个顺序继续：先看《Ubuntu 22.04 安装 Liwan 1.8 指南》把服务跑起来，再用《Liwan 1.8 配置参数详解》按自己的隐私与性能要求调参，日常维护与故障处理则交给《Liwan 1.8 运维实操指南》。
六、信息来源清单
本文全部事实性表述的来源与查询时间（2026-10-30，Asia/Shanghai）：
- liwan.dev 首页（产品定位、六大特性、Apache-2.0 许可、Docker 示例命令、SSO 支持、页脚仓库链接）；
- github.com/explodingcamera/liwan/releases.atom（v1.8.0/v1.8.1/v1.8.2 发布说明与日期）；
- shields.io GitHub Stars 徽章接口（Stars 219）；
- liwan.dev/install/binary/（平台支持与 musl 静态链接说明）；
- liwan.dev/reference/configuration/（配置项、默认值、DuckDB 段）；
- liwan.dev/collected-data/（采集白名单、访客分组五模式、不存储清单）；
- liwan.dev/guides/tracking/（追踪脚本、npm 包、属性上限）；
- Plausible、Umami、Offen、Shynet 各官网与 GitHub 仓库公开资料（对比表相应行）。