fetchpriority 在 script 标签上无效，仅对 img 和 iframe 生效；关键脚本执行顺序应通过 defer/async 控制，配合 preload + defer 组合实现早下载、早执行。
fetchpriority 在 <script> 标签上不起作用，无法调整关键脚本的执行顺序。
fetchpriority="high" 对 script 标签完全无效
浏览器（包括 Chrome 119+、Edge 101+、Safari 17.2+）会静默忽略 <script src="app.js" fetchpriority="high"></script> 中的 fetchpriority 属性。这不是兼容性问题，而是规范限制：该属性目前仅对 <img> 和 <iframe> 生效，且必须带非空 src。
-
<script>、<link rel="stylesheet">、<picture>、<video>上写fetchpriority—— 浏览器不报错，也不调度，等同于没写 - JS 动态创建的
<script>再调element.fetchPriority = "high"—— 属性只在 HTML 解析阶段读取一次，运行时赋值无效 -
<link rel="preload" as="script">上加fetchpriority—— 冗余，preload本身已锁定 Highest 优先级
真正影响脚本执行顺序的是 defer/async，不是 fetchpriority
控制脚本何时下载、何时执行，靠的是 defer 和 async，它们和 fetchpriority 完全无关：
-
defer：脚本并行下载，DOM 解析完成后、DOMContentLoaded前按声明顺序执行 —— 适合有依赖关系的首屏 JS（如 React + ReactDOM） -
async：下载完立即执行，不保证顺序 —— 适合完全独立的脚本（如统计、广告） - 无任何属性的
<script src="...">：同步阻塞解析，哪怕放在</body>前，也会卡住 DOM 构建
想让关键脚本“更快执行”，得靠 preload + defer 组合
单纯提高网络请求优先级不能解决执行时机问题。要确保关键脚本早下载、早执行，唯一可靠路径是：
立即学习“前端免费学习笔记（深入）”；
- 用
<link rel="preload" as="script" href="vendor.js">提前抢带宽（注意：必须配对as="script"和完整href，含查询参数） - 再用
<script src="vendor.js" defer></script>保证它在 DOM 就绪后按序执行 - 避免在
defer脚本里直接调用动态import()的模块 ——defer不等待这些异步操作，容易报ReferenceError - 如果脚本间存在深层依赖（如 A → B → C），静态属性兜不住，必须用 Promise 链或模块导入显式声明依赖
最容易被忽略的一点：CSS 阻塞链比 JS 更隐蔽。一个 <link rel="stylesheet"> 后面跟着的 defer 脚本，实际执行时间取决于 CSSOM 构建完成，而不是 HTML 解析结束 —— 这个隐式依赖不会在代码里体现，但会拖慢整个执行序列。
