onerror事件不会自动重试，需手动实现逻辑；正确做法是用data属性记录重试次数、动态更新src并防缓存，达上限后设fallback且移除onerror。
onerror 事件本身不会自动重试，必须手动触发
很多人以为给 <img alt="HTML怎么利用onerror限制请求循环重试" > 或 <script></script> 加上 onerror 就能“自动重试”，其实不然——onerror 只是一个回调函数，触发后什么都不会做，除非你显式写逻辑去重试。不手动调用 src 赋值或 reload()，就不会有第二次请求。
图片加载失败时最多重试 2 次的可靠写法
常见错误是直接在 onerror 里反复赋值 src（比如 this.src = this.src），这会导致无限循环：404 → onerror → 赋值 → 再 404 → 再 onerror……
正确做法是加计数器 + 清除事件监听，避免递归触发：
<img src="logo.png" data-retry="0" onerror="handleImageError(this)" alt="HTML怎么利用onerror限制请求循环重试" >
<script>
function handleImageError(img) {
const maxRetry = 2;
const retryCount = parseInt(img.dataset.retry) || 0;
if (retryCount < maxRetry) {
img.dataset.retry = retryCount + 1;
// 换个路径或加时间戳防缓存
img.src = img.dataset.src + '?t=' + Date.now();
} else {
// 彻底失败，可 fallback 到占位图
img.src = '/fallback.png';
}
}
</script>
-
data-retry存状态比闭包更可控，避免多个图片互相干扰 - 加
?t=...是为了绕过浏览器对 404 响应的缓存（部分浏览器会缓存失败响应） - 重试后必须移除或禁用原
onerror，否则新请求失败还会再进一次 —— 但这里用的是内联 handler，所以靠dataset控制次数更稳妥
script 标签重试要防止重复执行和竞态
<script onerror="..."></script> 的重试比图片更危险：脚本可能已部分执行、全局变量已污染、甚至引发 ReferenceError 后续还试图重载。
立即学习“前端免费学习笔记（深入）”；
- 不要用
this.src = this.src，会导致重复解析同一 URL（即使内容没变，也可能因 CORS 或 CSP 失败） - 推荐用动态创建
<script></script>元素的方式，每次新建节点，天然隔离执行环境 - 务必加
crossorigin属性，否则onerror在某些跨域场景下根本不会触发（静默失败） - 重试间隔建议加
setTimeout，避免瞬间刷爆请求（尤其 CDN 回源压力大时）
真正限制循环的关键是“状态隔离”和“出口明确”
所有基于 onerror 的重试逻辑，崩坏点几乎都出在状态管理上：共享变量、没清监听、没设上限、没区分资源类型。
- 每个资源实例（
<img alt="HTML怎么利用onerror限制请求循环重试" >/<script></script>）必须有自己的重试计数，不能共用一个全局retryCount - 一旦达到最大重试次数，除了换 fallback，最好也主动移除
onerror（比如this.onerror = null），彻底切断链路 - CDN 或代理返回 404 但带
Cache-Control: public, max-age=3600时，浏览器可能缓存该 404 响应 —— 此时重试永远失败，得靠服务端修复，前端只能降级
重试不是万能的，它只是容错手段；真正的稳定性来自资源路径治理、构建时校验、发布前探活 —— onerror 只负责兜最后一小段底。
