rel="preload" 仅预下载资源而不解析执行，无法直接获取API数据；需配合as="fetch"与立即fetch()复用连接，或改用内联JSON脚本。
rel="preload" 不是用来“取资源数据”的，它只负责提前触发资源下载，不执行解析、执行或渲染——想用它直接获取 API 数据或 JSON 内容，行不通。
rel="preload" 的真实作用范围
它只是告诉浏览器：“这个资源我马上要用，请现在就开始下载”，但不会自动调用 fetch()、不触发 script 执行、也不解析 link[rel="stylesheet"] 的 CSS 规则。常见误用是把它当 rel="prefetch" 或 fetch() 的替代品。
- 支持的
as值严格限定：比如script、style、font、image、audio、video、document（仅 iframe）、fetch -
as="fetch"是唯一能配合后续fetch()使用的类型，但它本身不发起请求，只预建立连接 + 预分配带宽 - 没有
as="json"或as="api"—— 浏览器根本不认识这些值，会降级为as="fetch"（如果忽略校验）或直接忽略
想预加载 JSON/API 数据？得配 as="fetch" + 手动 fetch()
这是唯一合规路径：用 rel="preload" 提前拉通网络链路（DNS、TCP、TLS），再立刻用 fetch() 发起实际请求，复用已建立的连接。
-
crossorigin必须匹配后续fetch()的凭据策略；若 API 需要 cookies 或 bearer token，必须加crossorigin="use-credentials" - href 必须与
fetch()地址完全一致（含协议、域名、路径、查询参数），否则无法复用连接 - 不能省略
as="fetch"—— 缺失时浏览器按as="xmlhttprequest"处理，部分浏览器不支持该值，导致 preload 失效
容易踩的坑：preload 后没用上，等于白干
很多项目写了 rel="preload" 却在几秒后才调用 fetch()，此时连接可能已被关闭，预加载失效。
立即学习“前端免费学习笔记（深入）”；
- 最佳实践：preload 后立即（同一事件循环内）触发
fetch()，例如放在标签里紧挨着写 - 避免在
window.onload或 ReactuseEffect里才 fetch —— 此时页面已渲染完毕，预加载意义不大 - Chrome DevTools 的
Network面板中，检查该请求是否显示Initiator: Preload，不是fetch或Other - 不要对动态拼接的 URL 使用 preload —— 预加载地址必须是静态可分析的字符串
比 preload 更适合“取数据”的其实是
如果数据量小、首屏强依赖（如配置、路由表），硬塞进 HTML 更快：
- 无需额外请求，DOM 解析时即可用
JSON.parse(document.getElementById('app-config').textContent) - 比 preload + fetch 组合少一个网络往返，延迟更低
- 不适合大体积数据或需鉴权的接口（会暴露在 HTML 源码中）
真正要发挥 rel="preload" 价值，得清楚它只管“下货”，不管“拆包”和“使用”。多数人卡在以为写了 preload 就等于数据到手了——其实连 fetch 都还没发出去。
