构建前端全链路监控大盘的关键在于日志可串联，需按spa、mpa、微前端、ssr/ssg四种运行方式实施差异化采集策略：spa绑定路由变更打结构化日志；mpa由服务端注入统一trace_id；微前端由主应用托管trace生命周期；ssr/ssg需融合服务端与客户端上下文。
构建真正可用的前端全链路监控大盘，关键不在日志“多不多”，而在“能不能串得起来”。所谓“四种运行方式的日志抓取矩阵”，本质是覆盖现代前端复杂部署形态的采集策略组合：单页应用（SPA）、多页应用（MPA）、微前端架构、以及服务端渲染（SSR/SSG）场景。每种形态下，日志的生成时机、上下文完整性、trace_id生命周期都不同——不针对性优化，就会出现链路断裂、日志失联、告警失焦。
SPA 场景：路由驱动的日志锚点必须绑定真实用户路径
单页应用中，页面不刷新但视图频繁切换，传统 PV 统计失效。日志不能只在初始加载时打一次，而需在每次有效路由变更（如 React Router 的 useEffect + useLocation 或 Vue Router 的 afterEach）时主动上报导航事件。
- 每次上报必须携带 from、to、isFirstEntry、navigationType（push/pop/replace）字段
- 关键业务节点（如“进入订单页→点击支付按钮→跳转支付宝”）要打结构化行为日志，而非仅记录 URL 变更
- 禁止用 window.location.href 当前值替代路由状态——SPA 中它可能滞后于真实视图
MPA 场景：服务端注入 trace_id 是唯一可靠起点
多页应用天然具备服务端入口，这是全链路对齐的黄金机会。所有 HTML 响应必须由网关或模板引擎注入统一 trace_id，且该 ID 必须与后端 SkyWalking / OpenTelemetry 入口 span 完全一致。
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 在 HTML head 中写入：<script>window.__TRACE_ID__ = "sk-xxx"</script>
- 后续所有 fetch / XHR 请求自动带上 traceparent（W3C 标准）或 X-Trace-ID header
- 资源加载（script/css/img）失败时，错误日志必须复用该 trace_id，而非生成新 ID
微前端场景：主应用托管 trace 生命周期，子应用只透传不生成
qiankun、micro-app 等框架下，各子应用独立打包、异步加载，若各自生成 trace_id，链路必然碎片化。主应用必须承担“链路中枢”角色。
- 主应用初始化时从服务端获取 trace_id，并通过 props 或 getAppData 向子应用透传
- 子应用禁止调用 Math.random() 或 Date.now() 生成 ID；所有请求拦截器、错误上报逻辑必须读取并继承该 ID
- 子应用间跳转（如从 dashboard 跳到 report）需触发主应用级路由事件，确保 trace_id 不因跨子应用而丢失
SSR/SSG 场景：首屏日志必须包含服务端渲染上下文
Next.js、Nuxt 等框架下，首屏 HTML 由服务端直出，客户端 JS 加载后才接管。此时若只采集客户端日志，会漏掉服务端报错、水合失败、TTFB 异常等关键问题。
- 服务端渲染时，将 trace_id、renderTime、isHydrationFailed、serverError（如有）注入 window.__INITIAL_STATE__
- 客户端 hydration 完成后，立即上报一条含 ssr: true、hydrationDuration、errorDuringHydration 的日志
- 所有首屏关键元素（如 banner、商品列表）的渲染完成时间，需通过 PerformanceObserver 捕获并绑定同一 trace_id
四种方式不是并列选项，而是生产环境共存的现实切片。日志抓取矩阵的价值，就是让每类流量都走对采集路径——不是靠 SDK 自动识别，而是靠架构约定强制对齐。链路不断、日志不散、告警不虚，大盘才真正立得住。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
