预加载图片需按场景选机制：link rel="preload"用于首屏确定关键图，必须静态路径、写在head最前、加as="image"；new image()适用于交互后按需加载，需先绑事件再赋值src并控制并发。
预加载图片不是“加个属性就变快”，而是要分清场景选对机制：link rel="preload"适用于首屏确定会用的图，new Image()适用于运行时按需触发的加载，二者不能混用或互相替代。
什么时候必须用 link rel="preload"
当你有明确的首屏关键图（比如 banner、logo、登录页主视觉），且路径在构建时就固定，就必须用它。这是唯一能在 HTML 解析阶段就发起请求的方式，能抢在 DOM 构建前把资源拉进缓存。
-
as="image"必须写，漏掉就退化成普通 fetch，Network 面板里 Priority 显示为 Low，Initiator 是 (Other) - 必须放在
最前面，紧贴<meta charset>后；动态插入（如document.createElement('link')）完全无效 - href 必须是静态字符串，不能含
${name}、./images/hero.jpg（相对路径易错）等；推荐用绝对路径如/assets/logo.webp - Chrome 101+ 可加
fetchpriority="high"，抬高请求优先级；旧版忽略，无副作用
为什么 new Image() 不能乱用
它适合用户交互后才决定是否加载的场景（比如 hover 按钮后预载下一页缩略图），但顺序和并发控制稍错就会失败或卡住。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 必须先绑定
onload/onerror，再赋值src；否则缓存命中时事件同步触发，回调直接跳过 - 要检查
img.complete === true，若为真，说明已缓存，需立刻执行成功逻辑 - 浏览器并发请求数通常只有 6~8 个，循环中密集
new Image()会导致排队阻塞；建议用 Promise 控制并发（例如每次最多 4 个） - 不要写
new Image().src = url这种简写，无法捕获失败，也无法链式等待
哪些写法看似像预加载，其实完全无效
最常见的误操作就是把延迟加载当成提前加载，或者用非标准方式干扰浏览器原生逻辑。
-
loading="lazy"是推迟加载，不是预加载；哪怕加在首屏<img>上，Chrome 仍可能等到滚动前 500px 才发请求 -
display: none或 CSSbackground-image伪隐藏，语义不清、Lighthouse 不识别、缓存策略不可控，且可能被浏览器优化掉 -
decoding="async"只影响解码时机，和下载时机无关；loading="eager"是默认行为，不等于“提前” - 同一张图既
preload又在<img src>中引用，但 href 和 src 路径大小写/斜杠不一致（如/logo.webpvslogo.webp），会导致二次请求
真正有效的预加载，核心就两条：路径必须静态准确，时机必须足够早。任何试图用 JS 动态拼接路径、或靠 CSS 技巧绕过规范的做法，都会在某个浏览器版本或网络条件下失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
