直接拼html+css做质量大盘越维护越累，因html不处理数据逻辑，图表、状态标记、阈值判断全硬编码进dom，改一个指标需同步修改html结构、内联样式和js数据赋值，系统增多后颜色映射、断点、id调用散乱，无法全局统一更新。
为什么直接拼HTML+CSS做质量大盘会越维护越累
因为HTML本身不处理数据逻辑，所有图表、状态标记、阈值判断都得硬编码进DOM——改一个指标就得翻三处：HTML结构、内联样式、JS里对应的数据赋值。一旦系统数量从3个涨到12个，document.getElementById调用开始重复、颜色映射规则散落在不同<script>块里、响应式断点被写死在<style>中，就再也无法靠“全局搜索替换”完成一次统一更新。</script>
用Chart.js + ECharts双库分工降低耦合度
Chart.js适合轻量级单图监控（如各系统构建成功率柱状图），ECharts负责多维联动大盘（如按环境/分支/时间下钻的失败率热力图）。关键不是选哪个库，而是把职责切开：
-
Chart.js只管“单点快照”：每个系统一个<canvas id="sys-a-build-rate"></canvas>，初始化时只传data.labels和data.datasets[0].data，不碰坐标轴配置 -
ECharts专攻“关联分析”：用echarts.init接管整个<div id="quality-dash">容器，通过<code>setOption动态合并来自多个API的JSON数据，共享tooltip和toolbox - 避免混用：不在同一个
<canvas></canvas>上既用Chart.js又用ECharts；也不用new Chart()去渲染需要联动筛选的图
数据层必须抽象出统一质量指标Schema
不同系统上报格式差异极大：Jenkins返回{"result":"SUCCESS"}，GitLab CI是{"status":"failed"}，自研平台可能用{"code":0}。硬写if-else转换必然失控。正确做法是定义最小公约数Schema：
{ "system": "payment-service", "env": "prod", "metric": "build_success_rate", "value": 98.7, "timestamp": "2026-06-30T14:22:00Z", "threshold": 95 }
所有接入系统先过一层适配器脚本，把原始响应转成这个结构再喂给图表。示例适配逻辑：
- Jenkins钩子：提取
response.result === "SUCCESS" ? 100 : 0 - GitLab CI回调：匹配
response.status === "success"则value=100，否则查response.failed_jobs.length算失败率 - 适配器输出必须带
system字段，这是后续分组聚合的唯一依据
响应式布局失效的三个真实原因及修复
质量大盘常在大屏崩溃，问题往往不在图表库本身，而在容器链路断裂：
-
<canvas></canvas>标签写了width="800" height="400"但没加style="width:100%;height:100%"→ Canvas像素尺寸固定，CSS缩放导致模糊 - 父
<div>没设<code>height，浏览器计算高度为0 → 图表初始化时getBoundingClientRect()返回0，resize()监听无触发 - 使用
vh单位但未处理移动端地址栏遮挡 → 大屏全屏时正常，手机横屏后100vh实际超出视口，滚动条出现
最简鲁棒解法：外层容器用style="width:100vw; min-height:100vh;"，图表初始化后显式调用chart.resize()，并在window.addEventListener('resize', ...)里加防抖。
真正卡住团队的不是写不出第一版大盘，而是当第7个系统要接入时，发现之前写的updateStatusBadge()函数里混着GitLab状态码映射、Jenkins颜色逻辑、还有硬编码的字体大小——这时候重构成本已经远超重写。把数据契约、容器约束、图表职责这三层边界划清楚，比选哪个库重要十倍。
