我认为＆lt; script type =“module”＆gt; 的一个流行用例将用于加载“主模块”，从中通过树来解析所有项目的依赖关系。 import 语句。但是，在网络上，似乎这会产生加载瓶颈，因为浏览器在解析 import 的依赖项之前无法知道要下载哪些脚本。与此对比的情况是，在最初提供的HTML文件中，单独的＆lt; script＆gt; 元素中引用了所有项目的脚本。在解析HTML时，脚本都可以并行下载。
将＆lt; script type =“module”＆gt; 创建加载瓶颈？页面上的多个＆lt; script type =“module”＆gt; 元素是否可以为彼此提供依赖关系，因此浏览器不一定需要下载和解析JavaScript以确定下一步要下载的内容？
我想这是HTTP / 2 PUSH_PROMISE的用例？服务器需要静态分析JavaScript文件并提前确定它们的依赖关系。但即使可以告诉浏览器提前下载模块，我想知道在解析 import 之前推送的模块是否仍然不会执行。至少使用＆lt; script＆gt; ，我知道他们会在第一时间执行。
答案 0 :(得分：8)
<script type="module">可以像<script> +动态模块加载器一样有效地加载模块。
多个<script type="module">可以为彼此提供依赖关系。来源（via IRC）：
我：如果我有一个
<script type="module" src="a.js">，那么＆＃34; a.js＆＃34;将export一个模块，我也有<script type="module" src="b.js">和＆＃34; b.js＆＃34;将import "./a.js";，将使用由前<script type="module" src="a.js">创建的模块的同一实例吗？annevk：如果他们在同一份文件中，是的
这是因为重复导入是从每个Window＆＃34;模块映射＆＃34; （见the spec）：
如果模块映射包含带有键 url 的条目，则使用该条目的值异步完成此算法，并中止这些步骤。
通过创建多个<script type="module">元素，我们可以避免＆＃34;依赖树的瓶颈＆＃34;通过让浏览器知道第一次机会下载所需的脚本。
＆＃34;模块脚本＆＃34;推迟对模块的评估，直到获取所有依赖项;而＃34;经典脚本＆＃34;只是执行，所以动态模块加载器理论上可以更快。但是，如果该动态模块加载器也阻止对依赖项的执行，那么它的任务可能需要与import一样长。此外，对性能的真正威胁可能是网络化;相比之下，评估可能是如此之快，以至于它是微不足道的。