如果要你从零开始设计一个前端日志埋点 SDK，你会怎么规划它的整体架构和核心模块？

回答思路

1. 【回答框架 1】一个可用的埋点 SDK 至少包含数据采集、数据存储、数据上报和配置管理四个核心模块。采集层负责监听用户行为或页面性能事件，统一封装事件类型、参数序列化和上下文信息，比如用户 ID、页面路径、时间戳等。
2. 【回答框架 2】存储层需要在内存中维护一个待发送队列，当浏览器空闲或请求失败时暂存数据，避免频繁上报影响性能。可以使用批量发送机制，将多条日志合并为一次请求，减少网络开销。同时要设置队列最大长度，防止内存占用过高。
3. 【回答框架 3】上报层应当支持多种传输方式，首选 sendBeacon 以保证页面卸载时数据不丢失，其次使用 XMLHttpRequest 或 fetch 作为降级方案。所有上报必须带有重试逻辑和超时机制，但重试次数要受限，防止雪崩。
4. 【回答框架 4】配置管理采用发布订阅模式，允许业务方动态开启或关闭某个埋点、调整采样率或修改上报地址。整体设计要遵循插件化思想，核心只负责调度，具体事件采集通过插件注册，便于按需加载和扩展。
5. 【回答框架 5】整个 SDK 需要在初始化时做错误捕获，任何插件异常都不能影响主流程。所有上报结果要有回调或状态日志，方便排查问题。对于隐私合规，要支持关闭采集或脱敏字段。
6. 【关键点 1】采用 sendBeacon 优先、fetch 降级的上报策略来保证数据可靠性。
7. 【关键点 2】使用批量队列和采样率控制来避免对主线程和网络的过度消耗。
8. 【关键点 3】通过插件化注册实现事件采集的按需扩展，核心逻辑与具体业务解耦。
9. 【关键点 4】必须具备全局错误捕获和失败重试上限机制，保证 SDK 自身健壮性。
10. 【关键点 5】初始化时提供动态配置接口，支持开关埋点和调整上报参数。
11. 【易错点 1】不要将所有上报都放在页面卸载事件里，因为 unload 中异步请求不可靠，应优先使用 sendBeacon。
12. 【易错点 2】避免上报数据直接包含敏感信息，要提供脱敏或白名单机制，否则容易引发合规风险。
13. 【易错点 3】重试逻辑不能无限重试，否则在服务端异常或网络故障时会放大请求压力，应设置指数退避或最大次数限制。