图片加载失败时onerror不触发是因为跨域未声明，需设img.crossorigin='anonymous'并服务端配cors头；预加载应分批+decode()防卡顿；texture销毁须等引用释放；webp兼容性需运行时检测而非仅看后缀。
图片加载失败时 onerror 不触发？检查是否漏了 crossOrigin
HTML5 游戏里图片加载失败却没报错，常是因为跨域策略拦截后静默失败——浏览器根本不会触发 onerror，除非显式声明跨域行为。
常见错误现象：Image 对象加载远程图源（如 CDN 或本地服务器）时黑屏、width/height 为 0，但控制台无报错；onload 不执行，onerror 也不执行。
- 使用场景：从非同源地址加载纹理、角色图、UI 资源（比如
https://cdn.example.com/sprite.png） - 必须设置
img.crossOrigin = 'anonymous'，且服务端需返回Access-Control-Allow-Origin响应头 - 若用
XMLHttpRequest或fetch预加载再转成BlobURL，也得带mode: 'cors'，否则后续drawImage会因污染 canvas 报SecurityError
预加载多张图时如何避免阻塞主线程？别用 for 同步新建 Image
一次性 new 几十张 Image 并设 src，看似简单，实则可能触发大量并发请求、内存瞬时飙升，甚至在低端设备上卡死渲染帧。
性能影响：浏览器对同一域名的并发连接数有限制（通常 6～8），密集创建会排队；每张图解析解码也占 CPU，尤其大 PNG 或未压缩 WebP。
立即学习“前端免费学习笔记（深入）”；
- 用
Promise.allSettled+ 分批加载，例如每次最多 4 张，完成一批再启下一批 - 给
Image对象加decode()调用（返回 Promise），确保解码完成后再进资源池，避免drawImage时触发同步解码卡顿 - 若引擎支持，优先用
createImageBitmap（传fetch的Response.body），它可 offscreen 解码，不阻塞主线程
Texture.from(image) 报错 “Tried to use a destroyed texture”？资源释放时机不对
Phaser、PixiJS 等引擎中，图片加载完立刻调 Texture.from，之后又手动 texture.destroy()，但若该 texture 正被某个 Sprite 引用，销毁后下一帧 render 就崩。
容易踩的坑：把预加载和资源管理混在一起写，没区分“加载完成”、“可用”、“已入池”、“可安全销毁”四个状态。
- 不要在
onload回调里直接destroy()或赋值给全局 texture 变量；先存到 Map 或 WeakMap，等确认不再被引用再清理 - PixiJS v7+ 推荐用
app.loader.add().load()统一管理，它自动处理引用计数；自建 loader 时，务必在Sprite.destroy({ children: true })后再清 texture - 调试技巧：打印
texture.baseTexture.resource?.url和texture.baseTexture.resource?.isLoaded，确认底层资源真实就绪
WebP / AVIF 图片加载快但兼容性差？用 picture + canPlayType 动态降级
游戏资源体积敏感，WebP 比 PNG 小 30%～50%，但 iOS 14 以下、老 Android WebView 根本不认 .webp 后缀，直接加载失败。
不能只靠文件后缀判断：有些安卓机支持 WebP 但不支持有损 WebP，或支持 AVIF 却不支持动画 AVIF。
- 运行时检测：
document.createElement('canvas').toDataURL('image/webp').indexOf('data:image/webp') === 0 - 更稳妥是用
fetch先试探 HEAD 请求，看响应Content-Type是否含webp，再决定用哪个src - 构建时生成多格式资源（PNG fallback + WebP primary），运行时按需选；注意 PixiJS 的
Texture.from不支持传URLSearchParams，得自己拼?v=202405避免缓存问题
资源路径和格式切换看似是配置问题，实际牵扯加载链路、缓存策略、引擎内部 resource 生命周期——一个 src 写错，后面全白忙。
