<template>比display: none更适合非首屏内容，因其完全不进入渲染流水线，不解析DOM、不计算样式、不占用渲染内存，仅在调用importNode时才实例化，配合IntersectionObserver可精准按需加载；而display: none仍参与DOM解析、CSSOM匹配和布局计算，拖慢首屏性能。
为什么<template>比display: none更适合非首屏内容
浏览器对display: none的处理是“构建但不绘制”——它仍参与DOM解析、CSSOM匹配、布局计算，只是跳过Paint阶段。对商品列表页后半截或长图文页的折叠章节，这会拖慢首屏解析速度，尤其在低端设备上明显卡顿。<template>则完全不进入渲染流水线：内容不被解析为DOM节点，不触发样式计算，也不占用内存中的渲染对象。
-
<template>内容只有调用document.importNode(template.content, true)时才真正实例化，配合IntersectionObserver可精准控制加载时机 - 若误用
display: none包裹500+行HTML，DevTools的“Layers”面板常显示大量闲置合成层，实为冗余布局计算残留 - 注意
<template>内不能直接执行<script>，需手动eval或appendChild后触发，这点和innerHTML不同
HTMLHeaderTextSplitter不配headers_to_split_on会直接OOM
默认只切<h1>，但门户网站文档普遍含<h1>–<h3>三级语义结构。漏配任何一级，对应层级就被吞进上一级块里——比如一个<h2>节被塞进前一个<h1>块，导致单块超500KB。向量化模型直接报MemoryError或Segmentation fault，根本跑不到渲染环节。
- 必须显式传入
headers_to_split_on=[("h1", "title"), ("h2", "section"), ("h3", "subsection")] - 若需保留每个
<p>所属标题路径（如生成面包屑），得加return_each_element=True - 含
<table>或<pre><code>的页面别硬套这个分割器，换用HTMLSemanticPreservingSplitter，否则表格跨行、代码缩进全乱
art-template多层继承中block命名冲突的真实后果
不是编译报错，而是静默覆盖：layout.art定义{{block 'content'}}，inner-layout.art也定义同名block，最终page.art里的{{block 'content'}}会直接覆盖中间层插入点，导致导航栏、侧边栏等区域内容消失——调试时看源码以为逻辑正常，实际渲染树里那部分节点压根没生成。
- 按区域+职责命名，例如
'header-nav'、'main-hero'、'sidebar-recommend'，避免泛用'content'或'body' - 所有
block名应在项目根目录下统一维护成JSON配置，构建脚本可校验重复命名 - 继承链超过三层（
layout → inner → feature → detail）会导致编译缓存失效率飙升，本地开发时修改一处常要重刷整个模板链
深层嵌套DOM如何拖慢Layout阶段
嵌套超过4层不是“建议避免”，而是会在线性拉高Layout耗时：每层div都可能触发独立的定位计算、边距合并、继承链遍历。Chrome DevTools Performance面板里，Layout事件Duration超过16ms就说明掉帧，常见于div > div > div > div > section > article这类结构。
立即学习“前端免费学习笔记（深入）”；
- 用
<main>、<section>、<article>替代纯容器，浏览器能跳过部分继承判断 - Grid/Flexbox不是万能解药——
grid套flex套grid反而增加计算负担，优先用Grid做页面级分区，Flex做组件内排列 -
table-layout: fixed对表格性能影响极大：设为auto时浏览器要扫全表内容定列宽，50行×10列文本表格可能卡顿200ms以上；设fixed后仅读第一行或<col>定义，宽度秒定
<template>内容虽不渲染，但若内部含未优化的CSS选择器（比如div div div p span），一旦被importNode插入，这些规则仍会拖慢后续CSSOM重建——组件化不是把问题藏起来，而是让问题暴露得更早、更准。 
