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

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

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

本文从技术架构、产品矩阵和工程方法论三个维度深度解析这个项目。

一、为什么需要 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

七、适用场景

总结

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

33k stars 的背后，是 Python/Django 的后端工程积累、React 的前端生态、以及垂直切片的清晰架构哲学。更难得的是它把公司运作方式也一并开源了——这种透明度的背后是真正的社区自信。

如果你的团队还在用多套分散的工具做产品分析，PostHog 值得认真考虑。

相关链接：

• 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自动更新