HTML静态错误页不可行，必须用data-status+fetch实现可感知、可重试、可恢复的动态失败状态，含语义化提示、上下文参数、递增重试、请求头标记及DOM清理。
HTML 本身不处理“结果页失败”——所谓失败状态，是 JavaScript 控制的交互逻辑，不是靠写个 <div class="error"> 就能生效的。关键在：错误必须可感知、可重试、可恢复，且不能脱离真实数据源。
为什么直接写 error.html 会出问题
把失败页面做成静态 HTML 文件（比如 error.html），等于把错误状态“硬编码”进前端。用户刷新、分享、回退时，页面永远显示同一个错误，而实际后端可能早已修复；更严重的是，它无法区分“网络超时”“接口 500”“订单不存在”等不同语义的失败，导致用户反复点重试却得不到响应。
- 浏览器双击打开
error.html时，所有fetch或XMLHttpRequest都会被file://协议拦截，根本发不出请求 - 没有上下文参数（如
order_id、retry_token）的错误页，重试按钮点下去只能报404或400 - 搜索引擎可能缓存这个静态页，把失败状态当成正常内容索引
怎么用 data-status + fetch 实现真失败状态
失败不是终点，是状态机的一个节点。必须用 JS 主动捕获、标记、反馈、重试。
- 容器元素加
data-status属性，如<main id="result-container" data-status="loading"> -
fetch失败后，在.catch()中设el.dataset.status = "error"，再插入含重试按钮的提示块（不要用innerHTML = "..."硬写） - 重试按钮绑定事件时，必须复用原始请求函数，而不是重新拼 URL —— 否则分页参数、token、时间戳全丢
- 点击重试前先设
data-status="loading"并禁用按钮，避免重复触发
错误文案和重试逻辑必须带业务上下文
“加载失败”这种文案毫无价值；用户需要知道“什么失败了”“为什么失败”“我现在能做什么”。
立即学习“前端免费学习笔记（深入）”；
- 错误提示里要嵌入具体资源标识，比如 “无法获取订单
ORD-789012的支付结果” - 如果失败源于参数缺失（如没传
order_id），重试按钮应不可用，并提示 “缺少必要参数，请检查链接是否完整” - 对超时类错误，重试间隔应递增（1s → 2s → 3s），避免压垮后端
- 所有重试请求需带上
Retry-Count请求头或 query 参数，便于后端识别并做限流
最常被忽略的：错误恢复后的 DOM 清理
重试成功后，很多人只改 data-status，却忘了移除之前插入的错误提示块。结果是成功内容和错误提示同时存在，或者旧提示块残留 DOM 导致后续 JS 查询错乱。
必须在 fetch 成功回调里执行：errorEl?.remove()，且确保清理逻辑不依赖于特定 class 名（比如不用 document.querySelector(".error-tip")），而是通过插入时保存的引用或唯一 data-id 定位。
