HTML 渲染 trace 详情页的 span 列表需依赖后端 API 或 SDK 提供 traceId 获取数据，页面按时间与层级结构化展示 span，动态计算缩进、裁剪字段、扁平化 tags/logs、统一处理时间戳，并支持懒加载单 span 详情及视觉化筛选慢/错节点。
如何用 HTML 渲染 trace 详情页的 span 列表
纯 HTML 无法主动拉取链路数据，必须配合后端 API 或前端埋点 SDK 提供的 traceId 请求数据。页面本身只负责结构化展示：按时间顺序排列 span，突出调用层级、耗时、状态和错误标记。
- 每个
span至少渲染：spanId、operationName、duration（单位 ms）、startTime（建议转为相对时间如 “+124ms”）、tags.error布尔值 - 用缩进或左 border 区分父子关系：通过
parentId和spanId构建树，再 DFS 展开；避免用 CSSmargin-left硬写层级，应动态生成style="padding-left: ${depth * 20}px" - 关键字段需加语义 class，例如
<span class="span-error">DB timeout</span>，方便后续用 JS 高亮或筛选
为什么不能直接用 JSON.stringify 显示 trace 数据
原始 trace JSON（如 Jaeger/Zipkin 格式）嵌套深、字段多、含二进制或 base64 编码的 binaryAnnotations，直接 JSON.stringify 会暴露无用字段（如 traceId 重复出现数十次），且无法关联服务拓扑。
- 必须做字段裁剪：只保留前端需要的字段，例如过滤掉
process中重复的serviceName，合并到每个span上 -
tags和logs是对象，需扁平化处理：把{"http.status_code": "500", "error": "true"}转成带 key 的列表项，而非原样输出{"http.status_code":"500"} - 时间戳统一处理：后端返回的
startTime通常是微秒级数字（如1712345678901234），前端需除以 1000 转毫秒，再用new Date()格式化或计算相对偏移
点击 span 查看详情时该请求什么接口
单个 span 的详情不是靠前端拼接出来的，而是调用独立的 span 查询接口，路径通常为 /api/spans/{spanId} 或 /api/traces/{traceId}/spans/{spanId}，取决于后端是否支持细粒度查询。
- 不要尝试在 trace 列表页预加载全部 span 的完整数据（内存爆炸），只加载摘要字段；详情按需懒加载
- 接口返回内容应比 trace 接口更全：包含完整的
logs数组（如每条日志的timestamp、fields）、解码后的binaryAnnotations（如http.url、db.statement） - 若后端不提供单 span 接口，就只能前端本地过滤：从已加载的 trace JSON 中
.find(s => s.spanId === clickedSpanId)，但此时logs和binaryAnnotations可能仍被压缩或缺失
如何让 trace 页面支持快速定位慢请求和失败节点
靠视觉线索，而不是滚动查找。核心是两件事：自动标色 + 可筛选的侧边栏。
立即学习“前端免费学习笔记（深入）”；
- 耗时着色规则写死在 CSS 里：
.span-duration[data-ms="5000"] { background-color: #ffebee; }，配合 JS 动态加 class，阈值设为 100ms（普通 RPC）、1000ms（DB）、5000ms（外部 HTTP） - 失败节点必须同时检查两个字段：
tags.error === "true"和statusCode >= 400（如果存在），仅凭status.code !== 0不可靠（有些 SDK 用 1 表示成功） - 侧边栏筛选器用原生
<select multiple>即可，选项值对应serviceName或operationName去重结果，选中后 JS 过滤 DOM 节点并scrollIntoView()到第一个匹配项
真正难的是跨服务时间对齐——不同机器时钟偏差会导致父子 span 时间倒置，前端无法修正，只能依赖后端已做 clock skew correction。这点容易被忽略，但一旦出错，整个调用瀑布图就不可信。
