SDK 项目逐字稿
使用方式
- 这页默认以
埋点 SDK为主稿，必要时再补监控 SDK 的边界和共性能力。 - 这页只保留
3 到 5 分钟版本和深挖版本。 - 默认先讲事件模型和数据质量，再补 SDK 分层和工程治理。
3 到 5 分钟版本
如果让我用 3 到 5 分钟讲 SDK 这条线，我通常会以埋点 SDK 为主，因为它最能体现我在模型设计、基础设施和平台治理上的能力。这个项目我不会讲成“封装一个 track() 方法”，而会讲成：怎么把业务里的用户行为稳定地翻译成一套可分析、可治理、可长期演进的事件语言。
这个项目最先要解决的不是 transport，而是事件模型。很多团队一开始做埋点，都是谁要分析数据，谁就在页面里补一个事件。短期接入很快，但长期会失控，因为事件名、字段口径和语义都会越来越散。所以我更倾向于把事件分层：底层保留 click、exposure、route-change 这类技术事件，但业务层尽量往“订单已提交”“任务已完成”这种稳定业务事件或领域事件靠。
在这个基础上，SDK 本身我一般会拆成四层。第一层是事件定义层，负责事件名规范、字段 schema、版本控制和分类。第二层是上下文层，自动补齐页面、来源、用户、设备、实验桶、会话这些公共字段。第三层是采集层，支持手动埋点和必要的自动采集。第四层是上报层，也就是队列、批量、重试、采样和 sendBeacon 兜底这些 transport 能力。
我觉得这个项目里最容易被低估的点，其实是数据质量治理。埋点最怕的不是少一点，而是看起来很多，实际上不能分析。所以我会补 schema 校验、必填校验、事件去重、调试面板和灰度抽样对账，让数据在进入分析平台之前就尽量可用。
所以如果总结这条线，我会说 SDK 的价值，不是把事件发出去，而是把业务行为稳定地表达、采集、校验和分析，让后面的分析平台、告警平台和业务决策真正建立在一套可信的数据语义上。
深挖版本
- 主稿表达：埋点 SDK 怎么讲
- 为什么强调领域事件：埋点为什么要靠近领域事件而不是 UI 事件
- 数据结构和建模：如何用履约建模法设计埋点平台数据结构
- 和监控 SDK 的边界：监控 SDK 和埋点 SDK 怎么区分边界
- 如果想补监控基础设施：前端监控 SDK 怎么讲
- 如果想补通用 SDK 设计方法：SDK 设计题怎么从需求讲到架构
- 高频追问与陷阱：埋点面试反问与陷阱题