PostHog：开源 all-in-one 产品工程平台，33k stars 的全栈方法论

🦔 PostHog 官方给自己的定位是：all-in-one developer platform for building successful products。

33.7k stars，MIT 协议开源（ee/ 目录的企业功能除外），代码库结构清晰，团队甚至把自己的公司手册（handbook）也开源了——从战略到工作方式到流程全透明。

下面拆成三块来看：技术架构、产品矩阵、以及工程团队的开源方法论。

读完你会拿到：

1. 列举 PostHog 的十大产品模块，说出每个模块解决什么具体问题
2. 用自己的话解释"垂直切分 + 依赖单向性"的架构原则，并举出一个违反原则的真实后果
3. 对比 Cloud 部署与自托管两种方式，判断自己的团队该选哪个
4. 面对一个具体需求（比如"想看用户报错前的操作路径"），能指出该用 PostHog 的哪几个模块组合

一、为什么需要 PostHog：解决产品开发的痛点

做产品的人通常面临几个痛点：

1. 数据散：Google Analytics 看流量，Mixpanel 看事件，FullStory 看回放，Sentry 看报错——五个工具，五套数据，互不相通
2. 定位慢：用户报错了不知道是怎么走到那个页面的，用户流失了不知道卡在哪一步
3. 发布险：Feature flag 能力弱，改个参数要重新发版，灰度全靠运气

PostHog 的解题思路是：把所有产品构建需要的数据能力聚合到一个平台，一次安装，全套拥有。

二、产品矩阵：十大能力一览

PostHog 目前提供以下十个产品模块：

2.1 产品分析（Product Analytics）

autocapture（自动采集）+ 手动埋点双轨并行，支持事件级分析、可视化图表和 SQL 查询。autocapture 会自动捕获点击、页面浏览、输入等行为，不需要手动埋点就能看到用户在做什么。

2.2 Web 分析（Web Analytics）

类 Google Analytics 体验，监控网站流量、会话数据和转化漏斗，天然集成 Core Web Vitals 和收入数据看板。

2.3 会话回放（Session Replay）

录制用户在网页或移动端的真实操作，播放交互过程，用于诊断可用性问题和还原 bug 现场。类似 FullStory，但原生集成在 PostHog 生态里，不需要额外采购。

2.4 Feature Flags

安全地将功能灰度推送给指定用户或群组，支持百分比分割、用户属性条件、过期时间等精细化控制。配合 Experiments 使用，可以做完整的 A/B 测试。

2.5 实验（Experiments）

在 PostHog 内部直接创建和运行 A/B 测试，测量变更对目标指标的统计影响，支持 no-code 配置。

2.6 错误追踪（Error Tracking）

捕获前端和后端异常，支持报警、分组、去重，并关联到具体的 session replay，帮你快速还原事故现场。

2.7 调研（Surveys）

no-code 问卷模板或自定义问卷，触达用户收集反馈，数据直接进 PostHog 分析。

2.8 数据仓库（Data Warehouse）

将外部工具（Stripe、HubSpot、自建数据仓库）的数据同步到 PostHog，和产品事件数据一起用 SQL 做联合分析。

2.9 数据管道（CDP - Customer Data Pipeline）

对流入数据做过滤和转换，实时或批量转发到 25+ 外部工具或任何 Webhook。

2.10 LLM Analytics

专门针对 LLM 应用的分析能力：捕获 traces、generations、latency 和 cost，让 AI 应用开发者也能像分析普通产品一样分析 AI 行为。

2.11 工作流（Workflows）

自动化操作和消息推送，支持根据用户行为触发工作流。

三、技术架构：Monorepo 分层设计

PostHog 的代码库是标准的 Python Monorepo，采用分层架构，核心设计原则是垂直切分（Vertical Slices）+ 依赖单向性。

3.1 顶层目录结构

posthog/              # 遗留单体代码（Django）
  api/                 # DRF views, serializers
  models/              # Django models
  queries/             # HogQL query runners

products/              # 产品垂直切分（推荐新代码放这里）
  <product>/
    backend/          # Django app（models, logic, api/, presentation/, tasks/, tests/）
    frontend/          # React（scenes, components, logics）
    manifest.tsx       # 路由、场景、URL 配置

services/              # 独立的业务服务（独立部署）
  llm-gateway/         # LLM 代理服务
  mcp/                 # Model Context Protocol 服务
  oauth-proxy/         # OAuth 代理（Cloudflare Worker）
  stripe-app/          # Stripe 集成应用

common/                # 共享代码（过渡层，逐步迁出）
  hogli/               # 开发者 CLI 工具
  hogql_parser/        # HogQL 解析器

tools/                 # 开发者/CI 工具（构建时使用，不被运行时代码引用）

devenv/                # 本地开发环境配置
platform/              # 跨领域基础设施（ aspirational，尚未创建）
  integrations/         # 外部适配器
  auth/                # Token 工具
  http/                # 共享 HTTP 客户端
  storage/             # S3/GCS 客户端
  queue/               # 消息队列辅助工具
  db/                  # 共享数据库工具
  observability/        # 日志、追踪、指标

3.2 核心设计原则：依赖单向性

文档里特别强调了一条铁律：platform 层绝对不能调用 product 代码。

原因很清晰：

• 如果 platform 导入并调用 product code，platform 就变成了一个隐藏的编排器
• 它必须知道有哪些 product 存在
• 依赖方向就会反转（platform → products）
• 随着时间推移，循环依赖几乎不可避免

所以 platform 是纯基础设施层，只能被 products/services 调用，不能反向。

3.3 Products：垂直切分的典范

每个 product 是一个完整的垂直切片：

products/feature-flags/
  backend/           # Django app（models, logic, api/, presentation/, tasks/）
  frontend/          # React（scenes, components, logics）
  manifest.tsx       # 路由 + URL 配置

产品之间不互相导入内部代码，通过 well-defined API 通信。这使得：

• 每个 product 可以独立开发、测试、部署
• 新人接手一个 product 不需要理解整个代码库
• 改动的影响范围天然隔离

3.4 Services：独立部署的业务逻辑

Services 是独立部署的微服务，有自己的领域逻辑，既不是 glue（ glue 是适配其他系统的），也不是 product（没有人直接使用它们）。

当前已识别的 services：llm-gateway、mcp、oauth-proxy、stripe-app。

3.5 HogQL：自定义查询语言

PostHog 自研了 HogQL——一个类似 ClickHouse SQL 风格的查询语言，用于在 PostHog 内部做事件分析。这是 PostHog 查询层的核心，让用户可以用 SQL 的方式分析产品数据。

四、SDK 生态：多端全覆盖

PostHog 提供了覆盖主流平台的 SDK：

几乎覆盖了所有主流开发平台，数据模型统一，一次埋点，全平台通用。

五、开源策略：透明到连公司手册都开源

PostHog 的开源策略有几个独到之处：

5.1 代码开源

主仓库是 MIT 协议，但 ee/ 目录（企业功能）有自己的许可证。这意味着：

• 核心功能全开源，任意使用
• 企业高级功能闭源，但许可证是透明的（不是黑箱）
• 如果需要 100% 纯开源（FOSS），可以用 posthog-foss 仓库，它已清除所有专有代码

5.2 公司手册开源

PostHog 把自己的公司手册也开源了（https://posthog.com/handbook），包含：

• 战略：为什么 PostHog 存在
• 文化：工作方式和价值观
• 流程：工程实践、产品开发流程

这在创业公司里极为罕见——把自己的思考过程和决策方式公开，让社区不仅能贡献代码，还能理解团队做事的逻辑。

5.3 定价透明

PostHog 的定价完全公开在官网（https://posthog.com/pricing），云版本每月有慷慨的免费额度（100 万事件、5k recordings、1M flag 请求、100k exceptions、1500 问卷响应），超出后才按量付费。

六、快速开始

云版本（推荐）：

# 访问 https://us.posthog.com/signup 或 https://eu.posthog.com/signup
# 免费额度：每月 100 万事件 + 5k recordings

自托管（Hobby 实例）：

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/posthog/posthog/HEAD/bin/deploy-hobby)"

最低配置：4GB 内存，支持约 10 万事件/月。

安装 SDK：

# JavaScript
npm install posthog-js

# Python
pip install posthog

# Node.js
npm install posthog-node

七、适用场景

八、常见问题

Q1：我们已经在用 Google Analytics 了，还需要 PostHog 吗？

场景：团队有 2-3 个产品，GA 看流量、手动埋点看事件、Sentry 收报错，数据散在三处，出了问题要来回切换。

GA 擅长的是页面级流量分析，PostHog 的优势在于事件级——它能告诉你"谁点了哪个按钮之后去了哪里"，并且把 session replay、error tracking、feature flags 串在同一个用户时间线上。如果你的产品有复杂交互（比如 SaaS 后台、在线编辑器），换 PostHog 能省掉至少两套工具。如果只是内容站看 PV，GA 够用。

Q2：自托管最低要多少资源？和 Cloud 版功能一样吗？

场景：团队做金融/医疗 SaaS，数据不能出境，只能私有化部署。

Hobby 实例最低 4GB 内存，撑 10 万事件/月。功能上，Cloud 和自托管的核心模块（Analytics、Replay、Feature Flags、Experiments、Error Tracking）一致，但 Cloud 多了一些托管便利性（自动升级、备份）。企业高级功能（ee/ 目录）需要单独授权，Cloud 和自托管都是如此。

Q3：PostHog 和 Sentry + Mixpanel + LaunchDarkly 组合有什么本质区别？

场景：团队已经买了 Sentry、Mixpanel 和 LaunchDarkly，三套数据不通，想评估是否值得迁移。

区别不在功能数量，而在数据模型统一。分散方案里，Sentry 的错误、Mixpanel 的事件、LaunchDarkly 的 flag 评估是三个独立的数据集，你没法在一条时间线上看到"用户开了 flag A → 触发错误 B → 在 session replay 里还原操作"。PostHog 把这几件事放在同一个用户/事件模型下，关联成本为零。代价是单点依赖——PostHog 挂了，这几块能力一起停。

Q4：HogQL 和标准 SQL 有什么不同？一定要学吗？

场景：团队有数据分析师，习惯用标准 SQL 写查询，担心 HogQL 学习成本高。

HogQL 是 ClickHouse SQL 的方言，语法和标准 SQL 90% 兼容，多了一些针对事件分析的快捷函数（比如 toDateTime()、漏斗分析语法）。日常的漏斗、留存、分群查询用可视化界面就够了，不需要写 SQL。只有做深度自定义分析（比如 JOIN 外部数据仓库的表）才需要写 HogQL。如果你会标准 SQL，上手 HogQL 大概 10 分钟。

Q5：PostHog 的免费额度够用吗？什么时候需要付费？

场景：3 人创业团队，日活几百，想知道能免费撑多久。

Cloud 免费额度每月 100 万事件 + 5k recordings + 100 万 flag 请求。以日均 1000 事件的小产品来算，免费额度完全够用。开始付费的典型节点是：recordings 超额（用户量大后回放消耗快）或者需要企业功能（SSO、权限控制）。自托管的 Hobby 实例也是免费的，只是你得自己运维。

自测

1. PostHog 的 autocapture 会自动采集哪些行为？什么场景下仍然需要手动埋点？
2. 为什么 platform 层不能导入 product 代码？如果团队里有人违反了这个规则，最可能引发什么问题？
3. PostHog 的 Feature Flags 和 Experiments 是什么关系？能不能只用其中一个？
4. 你正在做一个 LLM 应用，需要追踪每次 API 调用的耗时、token 消耗和错误率。PostHog 的哪几个模块能覆盖这个需求？为什么不能只靠 Error Tracking？

总结

PostHog 不是一个简单的"分析工具"，它是一个产品工程平台——把构建成功产品所需的全部数据能力打包在一起，从用户行为分析到会话回放、从错误追踪到 Feature Flag、再到 LLM 可观测性。

33k stars 不只是数字。代码库用 Python/Django 做后端、React 做前端，按垂直切片组织——这些工程决策沉淀在项目结构里，可以直接参考。更难得的是团队把公司手册也开源了，这意味着你不仅能读代码，还能看到他们为什么这么写。

如果你的团队还在用多套分散的工具做产品分析，可以从 Cloud 免费版开始试起：先接 Analytics 和 Session Replay，跑两周数据，再决定要不要把 Experiments 和 Feature Flags 也切过来。

相关链接：

• GitHub：https://github.com/PostHog/posthog（33.7k stars）
• 官网：https://posthog.com
• 文档：https://posthog.com/docs
• 公司手册（开源）：https://posthog.com/handbook
• posthog-foss（全开源版）：https://github.com/PostHog/posthog-foss

🦞 每日 08:00 自动更新