HTML模板技术本身不提供组件渲染优先级调度能力，它只是字符串生成工具，优先级控制依赖服务端组装顺序、客户端资源提示或框架hydration分区。
HTML模板技术本身不提供“组件渲染优先级调度”能力——它只是字符串生成工具，没有执行时序控制、资源调度或优先级干预逻辑。所谓“组件优先级”，实际是服务端或客户端在模板渲染前后插入的策略决策，不是模板引擎的功能。
模板引擎根本不管“哪个组件先画”
像 EJS、Nunjucks、Handlebars 这类模板引擎，本质是把数据 + 模板字符串 → 编译成 HTML 字符串。它不解析 DOM、不触发 fetch、不决定 fetchpriority 或 loading 属性是否生效，更不会主动排序组件输出顺序。你写 <%- header() %><%- main() %><%- footer() %>，它就按这个顺序拼；你调换函数调用顺序，它就换——仅此而已。
- 模板里写
<img src="hero.jpg" fetchpriority="high">，属性能保留，但是否生效取决于浏览器解析时机，不是模板决定的 - 用
include或partial引入子模板，只是文本包含，不产生异步加载、懒渲染或 hydration 分区 - 所谓“首屏组件优先”，其实是你在服务端手动把
header和main放前面，sidebar和ads放后面——靠的是 HTML 结构顺序，不是模板语法特性
真正影响组件“感知优先级”的三个外部环节
模板只负责“吐什么”，而“什么时候吐”“吐完怎么用”“吐出来后浏览器怎么处理”，由上下游环节决定：
-
服务端组装顺序：Node.js 中用
Promise.allSettled([header(), main(), sidebar()])并行获取数据，再按需排序传给模板——模板只接收已排好序的数据 -
SSR hydration 边界：React/Vue 的
renderToString生成 HTML 时，若组件内含useEffect或fetch，服务端直接跳过执行；客户端 hydration 时才补上。这导致“组件内容延迟出现”，不是模板慢，而是执行时机错位 -
客户端资源提示：模板中可静态写入
<link rel="preload" as="script" href="critical.js">或<img src="lcp.jpg" fetchpriority="high" loading="eager">，这些才是浏览器真正响应的优先级信号
容易被当成“模板调度”实则是误用的典型场景
很多团队以为在模板里加个 priority="high" 或用条件判断控制组件顺序就能调度渲染，结果发现无效——问题出在混淆了职责边界：
立即学习“前端免费学习笔记（深入）”；
-
<% if (isLCP) { %><%- hero() %><% } %>只是条件输出，不是“提升优先级”。如果hero()返回的 HTML 里没带fetchpriority="high"或尺寸属性，浏览器照样当 Low 处理 - 用
setTimeout(() => renderSidebar(), 3000)在客户端动态插入模板片段，反而破坏 SSR 一致性，导致 hydration 失败，且浏览器已进入空闲期，此时插入毫无优先级优势 - 模板中写
<script>document.postTask(...)</script>：Chrome 122+ 才支持postTask，且它调度的是 JS 任务，不是组件渲染；服务端模板根本无法执行该 API
关键点在于：HTML 模板是纯文本生成器，它不参与运行时调度。所谓“组件优先级”，要么靠服务端数据组装顺序和结构位置硬编码，要么靠客户端插入的浏览器原生信号（fetchpriority、preload、loading），要么靠框架层的 hydration 分区控制。把调度逻辑塞进模板，只会让问题更难定位、更难调试。
