直接回答：链路分四段：采集（SDK 劫持 window.onerror、unhandledrejection、框架错误边界，附加上下文：URL、用户、面包屑）、传输（批量压缩上报，采样控制量）、符号化（压缩混淆后的堆栈用 sourcemap 还原成源码位置与原始变量名）、聚合告警（指纹算法把同类错误归组，新增/激增触发告警）。sourcemap 的正确姿势是构建时生成并上传到监控平台，绝不发布到公网——否则等于公开源码。
展开解析：工程细节决定数据质量：release 一致性——上传 sourcemap 与事件上报必须带同一 release/dist 标识，版本错位就还原失败；隐藏 sourcemap——产物里删掉 //# sourceMappingURL 注释但保留文件上传（hidden-source-map），防抓取；栈帧还原率做指标监控，低于阈值（如 90%）要查构建链路（多阶段构建把 map 弄丢、CDN 路径与上传路径不匹配）。上下文质量比数量重要：面包屑（用户操作轨迹）与 tags（版本、灰度桶、AB 实验组）是定位的第一现场，用户隐私字段（输入内容）要 scrub。告警治理是长期活：指纹误判导致一个错误刷几万条（设速率限制与分组规则调优），噪音告警淹没真问题（按新增错误数而非总量告警）。性能监控（Web Vitals、长任务）通常复用同一 SDK，与错误关联（“这批白屏错误都伴随 LCP 飙升”）后定位效率倍增。
追问方向：跨域脚本的 Script error 无明细怎么解决？sourcemap 泄露的风险如何评估？
（约 490 字）