html-webpack-plugin是动态生成HTML的核心工具，但仅靠它无法支撑真正的组件化开发；必须结合html-loader在构建阶段解析HTML片段、支持data-props传参、统一组件路径管理，并通过PostCSS等工具实现BEM命名与样式隔离，才能解决SSI/PHP include导致的预览失效、热更新中断、样式污染等问题。

html-webpack-plugin 是动态生成 HTML 的核心工具，但仅靠它无法支撑真正的组件化开发。工程化里的 HTML 模块不是“写几个 include”就能完事的，它必须和构建流程、语义结构、类名规范咬合，否则只是把混乱从一个文件转移到多个文件。

为什么直接写 include 或 SSI 会失败

原生 <!--#include file="header.html"--> 看似简单，但开发时无法预览组件状态、热更新失效、样式作用域失控——这些不是“能跑就行”的小问题，而是阻断调试链路的硬伤。

• 浏览器不解析 SSI，本地双击打开就是空白或报错；必须走本地服务器（如 python -m http.server），但此时又没构建上下文，html-webpack-plugin 根本不介入
• PHP include 在开发环境依赖后端服务，前端开发者要配 Nginx + PHP-FPM，协作成本陡增
• 所有组件 HTML 片段里硬编码 class 名，一旦改名就得全局搜索替换，BEM 命名失去意义

html-loader + webpack 构建时注入才是正解

真正可行的路径是：用 html-loader 处理 .html 片段，在构建阶段解析并注入，同时支持 data-props 传参，让组件具备可配置性。

DeepBI DHTML 页面生成器

生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

下载

• 组件文件统一放在 src/components/ 下，命名带版本号（如 navbar.v2.html），避免多人修改冲突
• 在主模板中通过 require('./components/navbar.v2.html') 引入，html-loader 会自动处理相对路径和转义
• 若需传参，写成 <div data-props='{"theme":"dark","items":3}'></div>，再由配套 JS 解析，比字符串拼接安全可控

组件 HTML 内禁止硬编码 CSS 类名

所有样式必须通过 BEM 命名 + 构建时自动注入 scoped class 前缀实现隔离，例如 navbar__logo → navbar-v2__logo。

• 手动加前缀易出错，应交由 postcss 插件（如 postcss-bem）或自定义 loader 完成
• 若用 <template></template> 做运行时克隆，必须配合 Shadow DOM 或 contentDocument 隔离样式，否则全局 CSS 会污染组件内部
• Web Components 不是银弹：iOS Safari 对 adoptedStyleSheets 支持不全，slot fallback 在旧版 Edge 中可能错位，得提前测兼容性

组件复用的边界定义比技术选型更重要。一个 section 是否该拆成组件，取决于它是否能独立理解、可被单独测试或复用——而不是“看起来像一块”。