对于非首屏内容，推荐使用而非display: none，主要原因在于前者完全不进入渲染流水线——它不解析DOM、不计算样式、不占用渲染内存，只有通过importNode调用才会实例化。配合IntersectionObserver，可以实现精准的按需加载，从而提升首屏性能。相比之下，display: none虽然不参与绘制，但仍会执行DOM解析、CSSOM匹配和布局计算，拖慢首屏解析速度。这一差异在低端设备上尤为明显，是组件优化中需要重点关注的方向。

为什么比display: none更适合非首屏内容

浏览器对display: none的处理方式是“构建但不绘制”——它依然参与DOM解析、CSSOM匹配和布局计算，仅仅是跳过了Paint阶段。对于商品列表页的后半部分或长图文页的折叠章节，这种处理会延长首屏解析时间，在低端设备上容易出现卡顿。而彻底绕开渲染流水线：其内容不会被解析为DOM节点，不触发样式计算，也不占用渲染对象的内存空间。

• 调用document.importNode(template.content, true)时，的内容才真正实例化，结合IntersectionObserver可以精细控制加载时机，有效提升页面的渲染性能
• 如果使用display: none包裹超过500行的HTML，在Chrome DevTools的“Layers”面板中常能看到大量闲置的合成层，这些实际上是冗余布局计算留下的痕迹
• 需要注意的是，内部不能直接执行，必须通过手动eval或appendChild后再触发，这与innerHTML的行为不同

HTMLHeaderTextSplitter不配headers_to_split_on会直接OOM

默认情况下，该分割器只切分

，但门户网站文档通常包含

至

三级语义结构。只要遗漏任何一级，对应层级就会被吞入上一级块中——例如一个

章节被塞进前一个

块，导致单个块体积超过500KB。向量化模型在处理时会直接抛出MemoryError或Segmentation fault，无法到达渲染环节。

• 必须显式传入headers_to_split_on=[("h1", "title"), ("h2", "section"), ("h3", "subsection")]
• 如果需要保留每个
  所属的标题路径（例如生成面包屑），应添加return_each_element=True参数
• 对于包含或

  的页面，不要直接套用此分割器，应改用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这类结构。

  • 使用
    、
    、
    替代纯容器，浏览器可以跳过部分继承判断，从而提升渲染性能
  • Grid或Flexbox并非万能解药——grid套flex套grid反而增加计算负担。建议优先用Grid做页面级分区，用Flex做组件内排列
  • table-layout: fixed对表格性能影响显著：设为auto时，浏览器需要扫描全表内容来确定列宽，50行×10列的文本表格可能导致卡顿超过200ms；设为fixed后，浏览器仅读取第一行或
  定义，宽度立即确定

  在实际项目中，最容易被忽视的是内容虽不渲染，但若内部含有未优化的CSS选择器（例如div div div p span），一旦通过importNode插入，这些规则仍会拖慢后续的CSSOM重建。组件化并不是把问题藏起来，而是让问题暴露得更早、更准，从而在性能层面做好预防。