监控 SDK 和埋点 SDK 怎么区分边界
一句话先讲清楚
监控 SDK 更偏系统健康和体验观测，埋点 SDK 更偏业务行为和分析；底层链路可以共享，但事件模型和目的不一样。
30 秒版本
我会把监控 SDK 和埋点 SDK 分成两个层次来看。监控 SDK 主要回答“系统有没有问题、用户体验怎么样”，所以更关注错误、性能、白屏、接口异常这些信号；埋点 SDK 主要回答“用户做了什么、业务转化怎么样”，所以更关注曝光、点击、转化、漏斗和业务事件。两者底层可以共享 transport、上下文、队列和采样，但不能把事件语义混在一起。
1 分钟版本
如果让我区分这两个 SDK，我一般先从目标说起。监控 SDK 解决的是观测问题，核心是发现异常、评估体验、辅助定位；埋点 SDK 解决的是分析问题，核心是记录行为、还原路径、支撑转化分析。
所以它们虽然都在做“采集和上报”，但关注对象其实不一样。监控 SDK 更关心错误、性能、接口耗时、白屏这类系统信号；埋点 SDK 更关心曝光、点击、页面路径和业务事件。
在架构上我通常会让它们共享一部分基础设施，比如 transport、上下文补充、队列缓存、批量上报和页面退出兜底，但在事件模型上会明确隔开。因为监控数据和行为数据的用途、采样策略、分析方式都不同，如果混在一起，后面平台和治理都会变得很乱。
2 到 3 分钟版本
我会把这个问题理解成“哪些能力可以共享，哪些语义必须隔离”。
从目标上看，监控 SDK 更偏系统观测，主要是回答两个问题：系统有没有出问题，用户体验好不好。所以它关注的是 JS 错误、Promise 异常、资源加载失败、接口异常、Web Vitals、白屏这些信号。
埋点 SDK 则更偏业务分析，它关心的是用户做了什么、路径怎么走、哪些环节转化掉了。所以它更关注曝光、点击、路由、业务事件、转化漏斗和实验分析。
这两类能力底层当然有很多可以复用的地方。比如都需要一个稳定的 transport，都需要上下文字段，都要考虑批量、采样、限流、
sendBeacon、失败兜底。从工程实现上看，完全可以共享一部分底座。但我会特别强调，事件模型一定要分开。因为监控事件和埋点事件的语义、生命周期和使用人群都不一样。监控数据更多给研发和运维看，关注告警、排障和体验趋势；埋点数据更多给产品、运营、分析同学看，关注漏斗、路径和转化。如果你把两种数据混成一套事件语言，最后会出现采样策略冲突、字段治理混乱、平台视图互相污染的问题。
所以我的做法通常是“底座共享，语义分层”。也就是说 transport、队列、上下文、采样可以共用，但事件定义、分类、平台消费方式要区分开。这样既不重复造轮子，也不会把两个系统的边界打烂。
如果一句话总结，我会说监控 SDK 和埋点 SDK 是兄弟关系，不是同一个东西。它们可以共享基础设施，但不能共享业务目的。
如果面试官追问“能不能合成一个 SDK”
可以做成一个产品级大 SDK，但内部还是要分层。也就是说外部看起来可以是一套接入，内部仍然要把监控事件和埋点事件区分开，不然治理和分析会非常痛苦。
如果面试官追问“两个都要做采样，为什么还要分”
因为采样只是底层策略，事件的意义和消费方式还是不同。监控事件可能偏异常优先和告警优先，埋点事件可能偏业务完整性和实验分析优先，它们在采样策略上本来就可能不同。
最后一句收尾
所以我会让它们共享底座，但不会让它们共享语义。边界清晰，后面才不会越做越乱。