原生canvas画24小时温度曲线需先提取小时值并线性映射横轴，纵轴按实际温差动态缩放；注意api时区与字段名差异，推荐svg方案提升响应式与兼容性。
用 canvas 画 24 小时温度曲线最直接
不用引入大库，原生 canvas 加少量 JS 就能搞定。关键不是“怎么画”，而是“数据怎么对齐时间轴”。24 小时通常按整点切分（0:00–23:00），横轴要等距映射到画布宽度，纵轴得根据实际温度范围动态缩放——比如最低 12°C、最高 31°C，就不能硬写死 0–40 的刻度。
常见错误是把时间字符串（如 "2024-05-20T14:00:00"）直接当 X 坐标用，结果曲线挤在左上角。必须先提取小时值：new Date(timeStr).getHours()，再线性映射到 0–canvas.width 区间。
实操建议：
- 用
canvas.getContext('2d')获取上下文，别漏掉'2d' - 横轴起点统一用
Math.floor(new Date(item.time).getHours())，避免浮点误差导致点偏移 - 纵轴用
(maxTemp - temp) / (maxTemp - minTemp) * height计算 Y，注意 canvas Y 轴向下增长 - 画线前调用
ctx.beginPath()，否则多条曲线会连成一团
fetch 拿天气 API 数据时要注意时区和字段名
国内常用接口如和风、心知，返回的每小时预报字段名不统一：有的叫 temperature，有的叫 temp；时间字段可能是 obsTime 或 fxTime，且默认是 UTC 时间。直接渲染会导致曲线整体偏移 8 小时。
实操建议：
- 拿到时间字段后立刻转成本地时区：
new Date(apiTime).toLocaleString('zh-CN', {hour12: false, hour: '2-digit', minute: '2-digit'}) - 检查响应体结构，用
console.log(data[0])看清真实字段名，别凭文档硬写item.temperature - 如果 API 只返回未来 12 小时，别硬凑 24 点——要么补默认值，要么截断显示，别让
for循环越界 - 加个
loading状态，fetch异步特性会让初始渲染空白几秒
用 CSS + svg 替代 canvas 更适合响应式
如果页面要适配手机，canvas 的固定宽高会拉伸失真，重绘也麻烦。改用 svg + polyline，配合 viewBox 和 CSS 宽度控制，缩放自动保持清晰。
实操建议：
-
svg根元素设viewBox="0 0 240 100"，横轴 24 小时对应 240 单位，纵轴 100 单位代表温度区间 - 每个点的 X =
hour * 10（240 ÷ 24），Y =100 - ((temp - min) / (max - min) * 100) - 用
stroke="#4a90e2"和stroke-width="2"控制线条粗细，比 canvas 的lineWidth更易维护 - 别忘了给
svg加aria-label="24小时温度趋势图"，无障碍更友好
IE 不支持 canvas 或 fetch？老系统得降级处理
内网系统或政企项目还跑着 IE11，fetch 必须垫 whatwg-fetch，canvas 虽然支持但 toDataURL 有 bug。更稳妥的是用 svg 方案——IE9+ 都支持基础 svg 渲染，且不需要 polyfill。
实操建议：
- 检测
window.fetch存在与否，不存在就用XMLHttpRequest回退 - 避免用
Array.from()或扩展运算符解析 API 数组，IE11 不认，改用for循环 - 时间处理别用
Intl.DateTimeFormat，IE 对选项支持差，用date.getHours()最稳 - 如果必须用 canvas 且要兼容 IE，把绘图逻辑包进
try/catch，失败时 fallback 到纯 HTML 表格展示数据
真正卡住的往往不是画图本身，而是数据时间戳没对齐本地时区，或者 API 返回字段和文档不一致——这两处多打两次 console.log 能省半天调试时间。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
