modulepreload 不能减少长任务阻塞，因为它只提前下载模块而不解析、不执行、不构建模块图；真正触发长任务的是模块加载后的静态解析、首次 evaluate、顶层同步计算、动态执行等操作。
modulepreload 为什么不能减少长任务阻塞
它根本不管执行，只管下载。浏览器把 modulepreload 当作“提前发个 fetch 请求”，不解析、不执行、不构建模块图——所以它对 JS 执行时的长任务（如大型模块解析、编译、初始化）完全没影响。你看到主线程卡住 200ms，那一定是某个 type="module" 脚本正在 parse/compile/execute，不是 preload 没起作用。
哪些操作实际会触发长任务，且 modulepreload 无法缓解
以下行为发生在模块真正加载后，modulepreload 已经完成使命，不再参与：
-
import语句静态解析（尤其是含大量 export 的依赖模块） - Vite/Webpack 构建产物中带大量 helper 函数的 ES 模块首次 evaluate
- 模块顶层代码含同步计算（如 JSON.parse 大配置、正则预编译、全局 class 初始化）
- 依赖链中某模块用了
eval()或Function()动态执行字符串
真正能降低长任务阻塞的替代方案
想缩短主线程卡顿时间，得从执行环节下手，而不是下载环节：
- 把大模块拆成更小的 chunk，用
import('./feature.js')动态导入，让浏览器分批处理解析任务 - 对非首屏逻辑，改用
setTimeout(() => import(...), 0)或queueMicrotask延迟到空闲时段 - 移除模块顶层的同步副作用：把
initApp()改成导出函数，由入口控制调用时机 - 确认构建工具是否启用了
build.target（如'es2020'），避免生成冗余 polyfill 代码增加 parse 时间 - 用 Chrome DevTools 的 **Performance** 面板录制，定位具体哪个
Script Evaluation占用最久，而不是假设是“模块加载慢”
modulepreload 唯一能间接缓解长任务的场景
仅当你的长任务卡在“等待子模块网络请求”这个环节时，modulepreload 才有用——但它解决的是 RTT 延迟，不是执行延迟。例如：
立即学习“前端免费学习笔记（深入）”；
- 主模块
main.mjs静态 import 了utils.mjs和chart.mjs - 没写
<link rel="modulepreload" href="utils.mjs">→ 浏览器必须等main.mjs下载完、解析到import行，才发起utils.mjs请求 → 多一个 RTT - 写了且路径完全一致（含
?v=1.2.3）、CORS 正确 →utils.mjs和main.mjs并行下载 → 解析完main.mjs后可立刻开始utils.mjs的 parse
注意：这省下的只是网络等待时间，不是 parse/compile 本身耗时。如果 utils.mjs 自身就含 5000 行代码，它 parse 还是会卡主线程。
