innerHTML直接拼字符串虽可行，但模版变大、逻辑增多、多人协作时极易失控；真正风险在于改一处崩三处，而非加载本身。
innerHTML 直接拼字符串不是错，但一旦模版变大、逻辑变多、多人协作，就会立刻失控——真正的问题从来不是“能不能加载”，而是“改一处，崩三处”。
用 fetch() 加载外部 HTML 片段最稳的写法
现代项目基本都可用 fetch()，它比 XMLHttpRequest 更简洁，也比 jQuery 依赖更轻。关键不是调用，而是怎么防崩：
• 必须检查 response.ok，HTTP 404 或 500 不会自动 throw，await response.text() 仍会执行，结果是空内容或乱码
• 路径建议用相对路径（如 "templates/form-step-2.html"），避免硬编码域名或协议，方便本地调试和部署迁移
• 如果后端返回的是完整 HTML 文档（含 <html><head>），要额外用正则或 DOMParser 提取 <body> 内容，否则插入后会污染主页面结构
• 插入前清空容器？不建议直接 element.innerHTML = ""，而应保留原有节点引用再替换，否则已绑定的事件监听器会丢失（除非你用事件委托）
loadHTMLInto() 函数里必须处理的三类错误
封装成函数看似省事，但漏掉任一异常场景，用户看到的就是白屏或报错：
• 网络中断或 CORS 拒绝：fetch() 抛出 TypeError，需在 catch 块捕获，不能只靠 response.ok
• HTML 文件存在但解析失败（比如 UTF-8 BOM 导致乱码、标签未闭合）：response.text() 成功，但赋值给 innerHTML 后浏览器渲染异常，此时应加 try/catch 包裹赋值操作
• 容器元素不存在（ID 拼错、DOM 尚未就绪）：document.getElementById(...) 返回 null，后续调用 .innerHTML 报 Cannot set property 'innerHTML' of null，应在赋值前做存在性校验
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
为什么不用 iframe？它真没你想得那么“简单”
iframe 看似零 JS、兼容老设备，但实际埋雷极多：
• 样式隔离是双刃剑：主页面 CSS 不会穿透到 iframe 内，你得重复引入或内联样式，维护成本翻倍
• 跨域 iframe 无法读取 contentDocument，想统一控制按钮禁用、表单校验、滚动定位？做不到
• SEO 友好性差：搜索引擎通常不索引 iframe 内容，对内容型页面是硬伤
• 移动端体验问题：iOS Safari 对 iframe 高度自适应支持不稳定，常出现滚动条错位或空白区
stage-2.html 里有个 <button onclick="submitForm()">，如果 submitForm 在主页面定义，它能被调用；但如果这个函数是在 stage-2.html 里用 <script> 写的，那段脚本根本不会执行（innerHTML 插入 script 标签默认不运行）。这点，90% 的人第一次踩坑时都不知道。 
