Whatwg 规范描述了推测性 HTML 解析的概念。
因此，规范中有很多地方使用术语“主动推测解析器”。规范表示 HTML 解析器拥有并行执行的推测解析器实例。因此 HTML 解析器的解析和推测解析器的解析是并行执行的，彼此独立，拥有自己的资源。
我对一些事情感兴趣。
第一个。
Spec 表示推测解析器的行为类似于 HTML 解析器，但有一些限制，因此这意味着它执行与 HTML 解析器相同的步骤。
带有 名称为“script”的结束标记的示例。这是否意味着推测解析器将（独立）执行 HTML 解析器的所有步骤？
但是步骤呢：
如果活动推测 HTML 解析器为 null 并且 JavaScript 执行上下文堆栈为空，则执行微任务检查点。
该步骤是否会在 HTML 解析器和推测解析器的两个独立线程中执行？如果该步骤仅影响 HTML 解析器而不影响推测解析器，则应明确说明。您可以认为这是无稽之谈，因为推测解析器无法执行它的指令，因为该步骤不遵循条件：“推测解析器为空”。
好吧，那另一个算法中的例子呢：
如果活动推测 HTML 解析器不为 null，则返回给定命名空间、给定令牌的标签名称和给定令牌的属性创建推测模拟元素的结果。
现在你能说什么？我想知道哪些步骤可以应用于这个或那个解析器以及它们应该如何组合在一起。
第二个：
Spec 有算法推测性获取以及一些规则。其中一条规则描述：
如果推测性 HTML 解析器遇到以下元素之一，则就像该元素已被处理以达到后续推测性提取的效果一样。
这是什么意思：“就好像该元素是为了后续推测性提取的效果而被处理的。”？
感谢您阅读我的问题。
P.S 如果您出于任何原因想投反对票，请尝试在任何搜索系统中找到答案:)
从您的问题来看，尚不完全清楚您是否理解推测解析器的用途。回顾一下，它用于预取资源，而实际的 HTML 解析器在 parsing-blocking
<script><script src="script.js"></script>如果该步骤仅对 HTML 解析器有影响，而对推测解析器没有影响，则应明确说明。
确实如此。措辞“如果活动推测 HTML 解析器为空”的意思正是这一步不应由推测解析器执行。这是更正确的措辞，因为规范是作为伪代码编写的，并且最好依赖于集合变量的存在或不存在而不是半抽象类型。
所以，是的，脚本解析中的所有步骤都将被执行，但实际运行脚本的步骤除外。 （添加的注释是，如果我正确读取它，在这种情况下，待处理的解析脚本将为空，因此最后的步骤也不会运行）。
对于创建元素算法，由于它返回较早，因此它确实只会执行第一步，即创建一个模拟元素。请记住，我们希望它是轻量级的，不需要实际创建真正的 DOM 元素，这会比模拟的元素重得多且慢得多。
这是什么意思：“就好像该元素已被处理，以达到后续推测性提取的效果。”？
这意味着推测解析器必须表现得好像这些元素已被实际处理，并且它们的效果已应用到解析器上，即使它们尚未应用到实际解析器上。这是因为这些元素将影响获取的方式，因此推测解析器必须进行实际修改才能执行正确的获取。
因此，例如，如果推测解析器遇到<base href="https://example.com/">
，然后遇到
<img src="./image.png">，则必须考虑
<base>的
href才能获取正确的图像文件。