直接拼字符串不如用jsdom，因无法校验DOM树、不支持querySelector等API、样式脚本注入易错且难以动态修改；jsdom提供真实DOM编辑能力，需先创建JSDOM实例再获取document方可调用DOM方法。
Node.js 生成 HTML 文件时，为什么直接拼字符串不如用 jsdom？
因为原生字符串拼接无法做 DOM 树校验、不支持 querySelector 等选择器操作、样式和脚本注入容易出错，且后续想动态修改结构（比如加 class、删节点）就得重写整段字符串。而 jsdom 提供了接近浏览器的 DOM API，能真正“编辑”文档，不是“伪造”文档。
常见错误现象：document.createElement 在 Node 环境直接调用会报 ReferenceError: document is not defined；有人硬套浏览器代码，结果运行就崩。
- 必须先用
JSDOM构造实例，再取dom.window.document才能用 DOM 方法 -
createHTMLDocument是document.implementation下的方法，不是全局函数 - 生成后若要写入文件，得用
fs.writeFileSync，不能只靠console.log看效果
HTML 模板如何支持二次编辑而不破坏结构？
关键在保留语义化结构 + 预留可识别锚点。比如给容器加固定 id 或 data-editable 属性，而不是靠 class 名匹配——class 可能被 CSS 覆盖或重复，但 data- 属性是专为逻辑标记设计的。
使用场景：毕业设计里学生交作业后，教师需在生成的 HTML 上加批注；或 CMS 后台导出页面后允许运营人员微调文案。
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 避免用
innerHTML = 'xxx'全量覆盖，改用element.textContent或appendChild增量更新 - 脚本注入必须用
document.createElement('script')+textContent，不能拼进字符串，否则 XSS 风险高 - 如果模板含外部 CSS/JS，确保路径用相对路径或通过
<base href="...">统一控制，否则二次打开时资源 404
构建流中怎么处理静态资源引用（CSS/JS/图片）？
Node.js 生成 HTML 时，资源路径容易变成硬编码，导致本地双击打开正常、但部署到服务器就失效。根本原因是没区分开发态路径和运行态路径。
性能影响：路径错导致浏览器反复请求 404，拖慢首屏；兼容性影响：某些老版本 WebKit 对相对路径解析更严格。
- 统一用
./开头的相对路径，不要用/static/这类绝对路径（除非你明确配了反向代理） - 图片建议 base64 内联小图（
data:image/png;base64,...），避免额外 HTTP 请求；大图才走文件引用 - CSS 和 JS 若内容稳定，可直接内联进
<style></style>/<script></script>，省去外部加载阻塞
为什么 build 后的 HTML 不该依赖 Node 运行时？
工程化目标之一是产出可独立运行的静态文件。如果生成的 HTML 里还包含 require()、__dirname 或其他 Node 特有变量，那它就不是标准 HTML，而是“Node 模板片段”，没法直接扔进 Nginx 或 GitHub Pages。
容易被忽略的地方：有人用 fs.readFileSync 读取 CSS 内容再插入 style 标签，这代码只能在 Node 里跑；真正该做的是把读取动作放在构建阶段，输出纯 HTML 字符串。
- 所有
fs、path、require必须在构建脚本里执行完毕，最终写入文件的内容不含任何 Node API 调用 - 如果用了 Mermaid 或 Chart.js 这类前端库，确保它们是通过
<script src="..."></script>加载，而不是在 Node 里渲染成 SVG 再塞进去（那会失去交互能力） - 生成后的 HTML 应该能在任意浏览器双击打开，不报错、不白屏、样式功能完整
