link rel="preload"有时没效果，因路径错误、as类型不匹配（如as="font"缺crossorigin）、资源已被缓存标记为“已请求”而被静默跳过；Chrome DevTools中看不到请求可能是被合并或复用。
为什么 link rel="preload" 有时没效果
浏览器只在资源真正被用到前很短的时间窗口内预加载，如果 href 路径错、as 类型不匹配，或资源已在缓存中被标记为“已请求”，它就会静默跳过。Chrome DevTools 的 Network 面板里看不到该请求，并不等于没触发——可能只是被合并或复用了。
常见踩坑点：
-
as="font"必须配crossorigin，否则字体预加载失败且无报错 -
as="script"不能用于动态import()的模块路径，只对静态src有效 - 同一资源多次
preload不会重复请求，但会浪费解析时间 - 媒体查询不匹配时（如
media="(min-width: 1200px)"在手机上），该preload直接被忽略
link rel="preconnect" 和 dns-prefetch 怎么选
preconnect 建立完整 TCP+TLS 连接，开销大但后续请求更快；dns-prefetch 只做 DNS 查询，轻量但仅解决域名解析延迟。移动端弱网下，preconnect 可能因超时反而拖慢首屏。
实操建议：
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 对 CDN 域名（如
https://cdn.example.com）用preconnect，前提是确定 10 秒内必发请求 - 对第三方统计、埋点等低优先级域名，用
dns-prefetch更稳妥 - 不要对超过 2 个外部域名同时
preconnect，避免抢占主连接带宽 -
preconnect不支持media属性，无法条件化，需按实际设备能力判断是否注入
link rel="prefetch" 在 SPA 里容易误用
prefetch 是“空闲时加载”，适用于用户大概率下一步访问的资源（比如分页第二页的 JS、搜索建议接口的 JSON）。但在单页应用中，路由切换不刷新页面，prefetch 加载的资源若未被 JS 主动引用，就会滞留在内存里白占空间。
典型问题场景：
- 在首页
prefetch了「个人中心」JS，但用户全程没点进去 → 内存泄漏风险 - prefetch 的资源带哈希但未更新
href，导致加载旧版本，和当前 bundle 不兼容 - 服务端渲染（SSR）页面里 prefetch 了客户端才需要的模块，首屏反而多一次无效请求
- 未监听
document.visibilityState === 'visible'就发起 prefetch，后台标签页里浪费带宽
字体预加载必须绕开 CSS 解析阻塞
CSS 文件里的 @font-face 声明，要等整个 CSS 下载并解析完才触发字体请求，这会造成 FOIT（Flash of Invisible Text）。直接在 里用 preload 能提前至少 300–800ms 启动字体下载。
关键细节：
- 必须写全
as="font"+type="font/woff2"+crossorigin，缺一不可 - WOFF2 是首选，但得 fallback 到 WOFF 或 TTF，不能只 preload 一种格式
- 不要 preload 系统字体（如
system-ui）或本地已安装字体 - 字体文件体积超过 100KB 时，预加载收益下降，此时应考虑字体子集化或可变字体
最常被忽略的一点：所有这些 link 提示都依赖浏览器的内部调度器，而它的行为在 Chrome、Firefox、Safari 中并不完全一致；尤其 Safari 对 prefetch 的空闲判断更保守，部分机型甚至忽略 as="script" 的优先级提示。上线前务必用真实设备抓包验证。
