为何type=module的<script>标签执行顺序异常？如何排查？

针对你遇到的init.js及其依赖未按脚本标签顺序先执行，反而Y.js先运行的问题，可以从以下几个方向逐步排查：

1. 核查模块的网络加载时序 #

ES模块脚本的执行逻辑是加载完成后才会执行，如果Y.js比init.js（或它的依赖A.js/B.js）更早完成加载，就会先启动执行。

• 打开浏览器DevTools的「Network」面板，筛选「JS」类型，刷新页面后观察：
  • init.js、A.js、B.js的请求发起时间、响应完成时间是否晚于Y.js？
  • 这几个文件有没有出现加载延迟（比如服务器响应慢、缓存失效导致重新请求、资源优先级被浏览器调低）？
• 查看Waterfall视图，确认这几个模块的加载阶段是否被其他资源（比如图片、非模块脚本）抢占了带宽。

2. 检查模块的隐式依赖与潜在阻塞 #

虽然你提到init.js、A.js、B.js无异步逻辑，但要确认是否存在容易忽略的隐式操作：

• 检查A.js或B.js中是否存在动态导入（import()）、fetch、XMLHttpRequest等会发起网络请求的代码——哪怕这些操作是同步触发的，浏览器在处理请求时可能会调整资源调度优先级，间接影响模块的加载完成时间。
• 确认B.js中有没有修改全局状态、操作DOM的代码，会不会触发了其他脚本的加载或执行逻辑？

3. 排查浏览器预加载机制的异常 #

浏览器会自动预加载模块的依赖资源，但偶尔会出现预加载逻辑异常：

• 在「Network」面板开启「Preload」筛选，查看是否有Y.js被提前预加载的记录，而init.js的依赖（A/B）未被正常预加载？
• 检查页面中是否存在<link rel="modulepreload">标签，有没有人为提前预加载了Y.js，导致它的加载进度领先于init.js。

4. 排除非模块脚本的干扰 #

你提到页面中有不带type=module的库，即使无直接依赖，也可能影响模块加载：

• 临时移除所有非模块脚本，刷新页面测试执行顺序是否恢复正常，以此确认第三方库是否通过document.write、动态插入脚本、修改浏览器加载逻辑等方式干扰了模块的执行时序。

5. 利用性能调试工具追踪执行细节 #

• 打开DevTools的「Performance」面板，点击「录制」后刷新页面，结束录制后查看「Main」线程的时间线：
  • 找到init.js和Y.js的「Evaluate Script」阶段，对比两者的触发时间，看哪个先完成加载，以及执行触发的前置事件。
• 给init.js、A.js、B.js的第一行添加debugger;语句，触发断点后查看调用栈，确认脚本执行的触发原因，是否存在被其他逻辑延迟执行的情况。
• 检查「Console」面板是否有模块加载相关的警告或错误（比如某个模块加载失败导致init.js的执行被阻塞）。

内容的提问来源于stack exchange，提问作者KernelDeimos