HTML+CSS仅能静态展示订单状态，需后端提供status字段映射节点样式，用伪元素绘连线；轮询应基于next_update_at用setTimeout替代setInterval，并防抖；WebSocket须确认推送含完整状态字段且支持按订单订阅；地图与动效需权衡性能与必要性。
怎么用 HTML + CSS 实现基础订单状态流转图
纯静态 HTML 能做的只是「展示当前状态」，不能自动更新进度——这是前端最常误踩的坑。所谓“追踪”，本质是前端轮询或接收后端推送的状态数据，HTML 本身只负责把 status 字段映射成视觉节点和连线。
实操建议：
- 用
<ol></ol>或带data-status的<div> 列出关键节点（如“已下单”“骑手接单”“配送中”“已送达”） <li>每个节点加 <code>class="step active"或class="step completed"控制样式，避免用 JS 动态改 class 名引发重复逻辑 - 连线用伪元素
::after绘制，别用图片或 SVG 路径——维护成本高且响应式难适配 - 状态文案必须来自后端字段（比如
order.status === "DELIVERING"），前端硬编码 “配送中” 会导致多语言/运营改词时全量改代码 - 首次加载用
fetch拿全量状态，含next_update_at时间戳（后端预估下次变更点） - 用
setTimeout替代setInterval，每次取回新时间再设下一次拉取，避免“不管有没有变都死磕” - 订单进入
"DELIVERED"或"CANCELLED"状态后，立即清除定时器，防止无效请求继续发 - 加个简单防抖：如果两次响应的
status相同，不触发 UI 更新，减少 DOM 重绘 - 后端推送的消息体是否包含完整状态机字段？例如：
{ "order_id": "123", "status": "PICKED_UP", "rider_phone": "138****1234", "estimated_arrival": "2024-06-15T14:30:00Z" } - 连接断开时是否有重连机制？不要依赖
ws.onclose后手动点刷新 - 是否支持按订单 ID 订阅？避免全量广播导致客户端处理冗余消息
- 前端收到消息后，必须校验
order_id是否匹配当前页面订单，防止 A 订单页刷出 B 订单状态 - 用
<img src="/avatar/rider-789.png">+transform: translateX()模拟移动（配合后端返回的progress: 65百分比） - 方向变化靠
data-direction="north"切换 CSS rotate，别用 JS 实时算角度——没 GPS 坐标时纯属脑补 - 若真要地图，优先选高德/腾讯地图的「精简版 JS API」，禁用所有非必要控件（缩放、比例尺、版权文字），否则首屏加载超 2s
- 骑手电话脱敏显示写死为
138****1234，别用 JS 拼接——服务端该脱敏的必须脱敏，前端再处理是补救不是方案
为什么直接写 fetch() 轮询容易被节流或封禁
很多新手在页面里写 setInterval(() => fetch('/api/order/123'), 5000)，结果订单页卡顿、接口 429 频发。浏览器对高频同域请求有隐式限流，且无节流策略的轮询会浪费用户流量和服务器资源。
更稳妥的做法：
WebSocket 接配送状态前必须确认后端是否真推了关键字段
光在前端连上 WebSocket 不代表能实时追踪。常见翻车点是后端只推了“有新消息”，但没附带 status、updated_at、rider_location 这些字段，前端还得再发一次 HTTP 请求补全——那还不如不用 WebSocket。
接入前要核对：
地图定位和骑手头像动效的实际限制
想在页面里嵌个地图标骑手位置？先确认你用的 SDK 是否允许在非 HTTPS 页面加载（现代浏览器会直接屏蔽）、是否需要申请密钥、是否支持离线轨迹回放。多数轻量级订单页其实只需一个带方向的头像图标 + 进度条。
更现实的方案：
状态流转的边界条件比动画更重要：比如“骑手已出发但超时未到店”，这个异常态要不要进 UI？后端给不给 abnormal_reason 字段？这些才是影响用户体验的关键点，不是加个旋转 loading 就算“追踪”完成了。
