<p>纯 HTML 无法实现真正可用的骑行数据页，需结合 JavaScript 动态填充数据、CSS 控制仪表盘布局，并用 canvas 高效绘制实时曲线图，同时通过 data- 属性解耦结构与数据、JS 层平滑处理 GPS 抖动。</p>
纯 HTML 做不出真正可用的骑行数据页——它缺数据、缺交互、缺实时渲染能力，但你可以用 HTML 搭出结构骨架，再靠 JavaScript 填充真实数据，用 CSS 控制仪表盘式布局。下面直奔实操。
用 flexbox 布局骑行数据卡片（非响应式陷阱）
骑行数据页核心是多块「指标卡片」：当前速度、累计里程、心率、海拔、功率……它们需横向紧凑排列又保持可读性。别用 float 或绝对定位，display: flex 是唯一靠谱选择。
常见错误是给容器设 flex-wrap: nowrap 还不设 overflow-x: auto，结果在手机上直接撑破视口。正确做法：
- 外层容器用
display: flex+flex-wrap: wrap，保证小屏自动换行 - 每张卡片固定最小宽度（如
min-width: 120px），避免文字挤压变形 - 关键数值用
font-size: 1.8rem，单位用font-size: 0.9rem分开显示，别塞在同一个<span>里 - 避免对卡片用
width: 25%——不同设备列数不同，用flex: 1 1 120px更稳
canvas 绘制实时速度曲线图（不是 SVG）
折线图类数据（如速度随时间变化）必须用 <canvas>，SVG 在高频重绘（每秒 10+ 帧）时掉帧严重。HTML 只负责放一个空画布：<canvas id="speed-chart" width="400" height="120"></canvas>，其余全由 JS 控制。
立即学习“前端免费学习笔记（深入）”；
容易踩的坑：
- 别在
requestAnimationFrame里反复调用ctx.clearRect()清全画布——只清需要更新的区域，否则 iOS Safari 明显卡顿 - 横轴用时间戳差值（
Date.now() - startTime），别用数组索引，否则暂停/恢复时曲线错位 - 点太多就降采样：每 5 个原始点取 1 个，用
Math.floor(i / 5) === 0判断 - Canvas 默认是 devicePixelRatio=1，高分屏下模糊？加这三行：
const dpr = window.devicePixelRatio || 1;，然后缩放 canvas DOM 尺寸并重设width/height属性
用 data- 属性存原始数据，别写死在 HTML 里
很多人把「当前速度：24.3 km/h」直接写进 HTML 文本，结果 JS 更新时要反复 innerHTML 替换，破坏语义且难维护。正确方式是分离结构与数据：
<div class="metric" data-metric="speed" data-unit="km/h"> <span class="value">0.0</span> <span class="label">速度</span> </div>
JS 里统一监听 data-metric，用 document.querySelectorAll('[data-metric]') 批量绑定，更新时只改 .value.textContent。好处是：
- 后续加「英里单位切换」只需改
data-unit和 JS 转换逻辑，HTML 不动 - 无障碍支持更好：
aria-valuenow可动态同步到对应元素 - 服务端渲染时，这些
data-属性能被 SSR 框架（如 SvelteKit）原样保留，首屏不闪
GPS 数据延迟导致海拔跳变，CSS 无法修复
HTML/CSS 再漂亮，也压不住 GPS 海拔抖动（±15 米常见）。用户看到数字狂跳，第一反应是页面 bug。这不是布局问题，是数据问题——必须在 JS 层做平滑：
- 别直接用
position.coords.altitude，先推入长度为 5 的滑动窗口数组，每次取中位数 - 若连续 3 次海拔变化 > 3 米且时间间隔
- HTML 中对应海拔卡片加
transition: transform 0.2s ease-out，JS 更新时用transform: translateY()微调视觉反馈，比数字跳变更柔和 - 注意：iOS Safari 的
watchPosition在后台会暂停，别指望锁屏后还持续更新海拔
真正的难点从来不在怎么排版，而在怎么让一堆抖动、延迟、断连的真实传感器数据，在页面上看起来「可信」——HTML 只是最后那层纸，底下全是 JS 在兜底。
