HTML解析器与推测性解析器的交互及WHATWG规范相关疑问

问题1：推测性解析器的执行步骤与协作逻辑 #

• 遇到script结束标签时，推测性解析器是否独立执行所有步骤？
  推测性解析器是带限制的HTML解析器，它会执行和主解析器一致的核心解析步骤，但会跳过所有会修改主文档状态的操作。遇到script结束标签时，它会独立完成自身流程里的对应步骤，但不会触发脚本执行、DOM修改这类主文档相关的操作——它的核心目标是提前扫描资源，而非构建真实DOM。

• 微任务检查点步骤是否会在两类解析器的独立线程分别执行？
  不会。微任务检查点的触发条件明确要求active speculative HTML parser为null，所以推测性解析器的线程完全不会触发这个步骤。这个设计是为了避免预扫描逻辑干扰主解析器的微任务队列，毕竟推测性解析是并行的“预操作”，不参与主文档的执行上下文生命周期。

• create an element for the token算法中两类解析器的适用步骤与协作方式？
  这个算法是主解析器和推测性解析器共用的，但通过分支逻辑区分场景：

  • 当active speculative HTML parser不为null时，返回的是推测性模拟元素——这个元素不会被插入主DOM，仅用来模拟元素的上下文（比如判断资源加载的条件、父元素对资源的影响等），为推测性预取提供依据。
  • 主解析器执行时，会创建真实的DOM元素并插入文档。
    两者的协作逻辑是：推测性解析器通过模拟元素流程提前收集资源预取信息，主解析器正式解析时，可复用已完成的预取请求（如果请求依然有效），但完全不依赖推测性解析的DOM模拟结果。

问题2：推测性获取（speculative fetch）相关规则与注释解析 #

• “若推测性HTML解析器遇到以下元素之一，则为后续推测性获取的效果而模拟处理该元素”的含义？
  这句话的核心是通过模拟元素处理流程触发预取。推测性解析器遇到link、img这类资源型元素时，不会真的创建DOM元素插入文档，而是会模拟执行该元素的初始化流程（比如解析src/href属性、判断资源类型、检查CORS规则等），目的是提前发起资源请求。等主解析器正式处理到这个元素时，请求可能已经完成或在进行中，以此提升页面加载速度。

• create an element for the token步骤2注释的含义？
  这个注释是说，主解析器执行时也可能触发推测性获取——此时调用该算法创建的模拟元素不会被实际使用（主解析器后续会创建真实元素），但这个步骤的作用是触发预取逻辑。而且这种预取依然是“推测性”的：比如主解析器创建元素后，可能因为JS操作（比如将父元素从文档中移除）导致该元素不会被插入DOM，那之前预取的资源就可能无用，但浏览器依然会进行预取，以此换取大概率的性能收益。

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