前端稳定性报警与日志追踪需以服务端注入的统一TraceID贯穿全链路，强制对齐后端SkyWalking/OpenTelemetry，结构化上报并绑定多维标签，实现精准告警与根因定位。

前端运行稳定性报警与日志追踪大盘不能只靠埋点 SDK + 上报 + 前端监控平台拼凑出来，必须让 TraceID 从页面加载开始就贯穿请求、资源加载、错误、用户行为、上报全过程，并与后端链路对齐——否则所谓“全链路”只是前端单点幻觉。

前端如何生成并透传统一 TraceID

关键不是“有没有 ID”，而是这个 ID 是否能和后端 SkyWalking / OpenTelemetry 链路天然对齐。手动拼接或随机生成的 trace_id 在跨域、重定向、微前端场景下极易断裂。

• 推荐在 HTML 模板首次渲染时，由服务端注入一个全局变量 window.__TRACE_ID__ = "xxx"，该值应与后端入口（如 Nginx 或网关）生成的 trace_id 一致
• 所有 XHR / Fetch 请求必须携带该 ID 到 traceparent（W3C 标准格式）或自定义 header（如 X-Trace-ID），避免被 CORS 拦截需提前配置 Access-Control-Expose-Headers
• 微前端场景下，主应用负责初始化并透传，子应用通过 props 或 qiankun 的 getAppData 获取，禁止各子应用自行生成
• 注意：Sentry、Bugsnag 等错误监控 SDK 默认不传递 trace_id，需手动 patch beforeSend 钩子注入

前端日志如何与后端链路一键关联

日志字段里写个 trace_id: "abc123" 不等于“可关联”。ELK 或 Loki 能否按此字段快速跳转到 SkyWalking 对应链路，取决于日志结构、索引策略和前端上报时机。

• 前端日志必须结构化为 JSON，且顶层字段包含 trace_id、span_id、timestamp（毫秒级）、level、msg、url、ua
• 上报日志时，务必复用同一 trace_id，并在 span_id 中体现层级（例如：根 span 用 root，API 请求用 api-/order/list）
• 避免日志打点过载：用户滚动、鼠标移动等高频事件不打日志；只保留 error、warn、关键业务节点（如“下单按钮点击”、“支付回调成功”）
• Loki 中需配置 __labels__ 包含 trace_id，Grafana 查询时才能用 {trace_id="xxx"} 直接联动 SkyWalking 的 trace 查看页

哪些前端指标真正影响稳定性报警有效性

“JS 错误率 > 0.5%” 这类告警毫无意义——它既不区分错误类型，也不区分影响面，更无法触发精准定位。真正可用的报警必须绑定上下文维度。

前端开发

ys-agent 前端（frontend/）功能迭代的工程规范守门 skill。当任何 agent 接到 ys-agent 前端相关任务时——新增页面、新增组件、加 API、加 Pinia store、改路由、写 mock、调整布局、修改样式、对接后端接口、迁移 demo 代码、做主题、加权限、写公共组件、做数据可视化、做表单、做弹窗、做表格、做搜索过滤、调 Element Plus 用法、做响应式、做性能优化，或仅仅是在 frontend/ 目录下编辑任何 .vue / .ts / .scss / .c

下载

• 优先监控：白屏率（首屏内容为空的 PV 占比）、接口失败率（非 HTTP 5xx，而是 fetch().catch 或响应体含 code !== 0）、资源加载失败率（script/css 的 onerror）、长任务阻塞（longtask API 统计主线程连续阻塞 ≥ 50ms 的次数）
• 报警必须带标签：按 env（prod/staging）、page（/cart /pay）、browser（Chrome 124+ / Safari 17.5）、region（cn-shenzhen / us-west）切分，否则一告警就全量推送，运维直接静音
• Prometheus 不适合直接采集前端指标，改用 Grafana 的 Alerting rules 基于 Loki 日志聚合结果触发（例如：过去 5 分钟内 level="error" | json | trace_id != "" | __error_type__ == "network_timeout" 出现 ≥ 10 次）
• 避免“告警风暴”：对同一 trace_id 下的多个错误，只告警根因（如首个 JS error 或首个网络失败），其余标记为 caused_by

为什么你搭的大盘查不到“那次用户点击没反应”

因为前端链路断在了最前面：没有记录用户操作前的环境快照，也没有把用户行为（click/tap/input）作为 Span 显式创建，导致日志和追踪里只有“空白请求”和“报错”，却找不到“谁、在哪、点了什么之后崩的”。

• 必须将关键用户交互封装为 performance.mark() + 自定义 Span：例如 startSpan("ui-click-checkout-btn")，并在后续 fetch 完成后 endSpan()
• 上报日志时，自动捕获 document.activeElement、location.href、performance.navigation.type、performance.getEntriesByType("navigation")[0].type（reload / back_forward）
• 不要依赖 console.error 自动捕获——它拿不到堆栈上下文里的变量值；改用 try/catch + Error.captureStackTrace（Node.js 风格）或 stacktrace-js 做增强采集
• 移动端真机问题最难复现？在日志中强制带上 screen.width x screen.height、devicePixelRatio、navigator.connection.effectiveType，这些字段比“iOS 17.6”有用十倍

最常被忽略的一点：前端链路的起点不是 DOMContentLoaded，而是 navigationStart —— 如果你没在 performance.timing 或 Navigation Timing API 里取这个时间戳，所有耗时计算都会偏差 100~300ms，而这个偏差，刚好掩盖掉 CDN 缓存失效、DNS 预热失败这类真实瓶颈。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！