html模块化结构应直接用header、nav、main、section、aside、footer等语义标签划分区域，避免div套嵌；须保持文档流自然解析，禁用position: absolute或float脱离流，动态插入优先用insertadjacenthtml而非innerhtml。
HTML 模块化结构怎么拆才不破坏语义和渲染流
模块化不是把 <section></section> 套一层 <div class="module"> 就完事。关键在于拆分后仍能被浏览器按文档流自然解析，且不引入隐式重排或样式污染。
<p>常见错误是用 <code>display: contents 或 visibility: hidden 包裹模块，结果导致语义丢失（如屏幕阅读器跳过）、focus 顺序错乱、或 CSS :focus-within 失效。
- 优先用语义化标签（
<article></article>、<aside></aside>、<nav></nav>）做天然模块边界，而非纯<div> <li>避免在模块根节点上设 <code>position: absolute或float—— 这会让它脱离文档流，影响后续模块的布局上下文 - 如果必须动态插入模块（如 SPA 中的懒加载区块），用
insertAdjacentHTML('beforeend', ...)替代innerHTML，避免重置已绑定的事件监听器 -
<script></script>标签必须带defer（顺序执行、不阻塞 parser）或async（无序执行、适合独立工具类），禁用无属性内联脚本 - Critical CSS 提取到
<style></style>内联，非关键 CSS 用<link rel="preload" as="style" onload="this.rel='stylesheet'">+onload回调切换 - 对
<img>和<iframe></iframe>加loading="lazy"，但首屏图片必须显式设fetchpriority="high" - Vite 中启用
build.rollupOptions.input指向多个 HTML 入口，每个入口对应一个首屏模块组合，避免单页全量加载 - Webpack 下慎用
html-loader处理含<script type="module"></script>的片段 —— 它会把import当成字符串处理，导致运行时报ReferenceError: require is not defined - 所有模块级 HTML 片段里禁止出现
、、根标签，只保留片段内容（如<section>...</section>） - 用
<link rel="preconnect" href="https://fonts.googleapis.com">提前建立字体域名连接，比preload更早生效 -
<img>和<video></video>必须显式声明width和height属性（非 CSS），否则浏览器无法预留空间，导致重排延迟 LCP - 检查是否在首屏模块中意外引入了未标记
crossorigin的第三方 script —— 它会因 CORS 策略降级为匿名模式，触发额外预检请求
如何让首屏 HTML 不被 JS/CSS 阻塞渲染
首屏阻塞根源不在代码量大小，而在资源加载时机与执行依赖链。哪怕只有 1KB 的 <script></script> 放在 里，只要没加 defer 或 async，就会 halt HTML parser。
实操时最容易忽略的是 CSS：即使 <link rel="stylesheet"> 在 底部，浏览器仍会阻塞首屏渲染，因为 CSSOM 构建是渲染前必经步骤。
按需打包 HTML 模块时 Webpack/Vite 怎么配才不翻车
HTML 本身不是 JS 模块，所以不能直接用 import('./module.html')。所谓“按需打包”，本质是服务端模板注入或构建时静态拼接，工具链配置稍有偏差就会输出无效 HTML。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
Vite 的 html-plugin 或 Webpack 的 html-webpack-plugin + html-loader 组合最常踩坑：路径解析错、<script></script> 标签重复注入、base 路径丢失。
首屏防阻塞后，为什么 LCP 还是超时
LCP（Largest Contentful Paint）卡在 4s+，往往不是 JS 执行慢，而是资源发现晚或渲染路径长。比如一个 <picture></picture> 里写了 5 个 <source></source>，但浏览器要等全部解析完才选最优源，期间可能错过关键帧。
另一个隐形杀手是字体加载策略：font-display: swap 虽能防 FOIT，但若 fallback 字体行高与实际字体差异大，会触发 layout shift，间接拉长 LCP 时间。
真正难的不是知道该做什么，而是判断哪一行 HTML 正在悄悄拖慢首屏。建议用 Chrome DevTools 的 Performance 面板开启“Screenshots”，逐帧看 DOM 构建与绘制节奏，比单纯看 Lighthouse 报告更准。
