HTML import 已废弃，仅执行脚本而不解析 DOM、样式或模板；现代方案应使用 ES 模块配合 fetch/DOMParser 动态加载并手动解析 HTML 片段。
HTML导入（import）根本不会触发文件解析
HTML import 是一个已被废弃的 Web Components 规范特性，它只做一件事：下载并执行导入的 HTML 文档中的 <script></script>，**不解析其中的 DOM 结构、不挂载样式、不处理 <link rel="stylesheet"> 或 <template></template> 等标签**。浏览器拿到响应体后，仅提取并运行脚本，其余内容被完全忽略。
这意味着：<div id="widget">...</div> 这类结构即使存在，也不会变成实际 DOM 节点；<style></style> 标签里的 CSS 也不会生效——除非你手动读取 document.body.innerHTML 并插入，但那已不属于 import 行为。
- Chrome 73+ 已彻底移除
import支持，无 polyfill 能完整还原语义 - 所谓“导入 HTML 文件”本质是 XHR + 手动解析，不是原生能力
- 如果看到“HTML 导入成功”，大概率是某框架或构建工具在拦截请求后做了额外处理
真正需要文件解析的场景，其实是动态加载 HTML 片段
当你想把一个外部 HTML 文件（比如 sidebar.html）的内容插入到当前页面时，浏览器不会自动帮你解析它——你必须显式调用解析逻辑。常见做法是：
- 用
fetch('sidebar.html')拿到文本响应 - 创建临时容器：
const div = document.createElement('div') - 赋值：
div.innerHTML = responseText—— 这一步才触发 HTML 解析（包括脚本执行、样式注入、DOM 构建） - 再把
div.children或特定节点 append 到目标位置
注意：div.innerHTML = ... 中的脚本默认**不会执行**（除非你用 createContextualFragment 或手动 eval），这是安全限制，也是容易踩坑的地方。
立即学习“前端免费学习笔记（深入）”；
innerHTML 解析和真实 HTML 文档解析的区别
innerHTML 的解析行为受限于上下文：它按“fragment parsing algorithm”处理，不触发 <base>、不解析 <meta>、忽略 内容，且脚本只有在插入到文档树后才可能执行（取决于插入方式）。
- 直接
el.innerHTML = '<script>console.log(1)</script>'→ 不执行 - 用
document.adoptNode()或el.appendChild(scriptEl)→ 可执行 -
<link rel="stylesheet">在innerHTML中会被创建为节点，但**不会发起网络请求加载 CSS** - 相对路径（如
src="./img.png"）会以当前页面 URL 为基准解析，不是以 HTML 文件所在路径为准
现代替代方案：不要用 HTML 导入，改用模块化加载
如果你的目标是复用 HTML 结构 + 逻辑 + 样式，import 从设计上就不适合。更可靠的做法是：
- 将组件封装为 ES 模块（
.js），用export async function render() { ... }返回 DOM 片段 - 样式走
CSS Modules或constructable stylesheets（new CSSStyleSheet()） - 模板用
lit-html或原生template+content.cloneNode(true) - 构建时预编译 HTML 字符串为 JS 字面量，避免运行时解析开销
硬要加载外部 HTML？那就老老实实 fetch + DOMParser（注意：DOMParser 解析出的文档是孤立的，脚本不执行、样式不生效，仍需手动迁移节点）。
最常被忽略的一点：HTTP 响应头里的 Content-Type 必须是 text/html，否则 fetch 的 response.text() 可能乱码，而 response.blob() + text() 又绕不开编码探测——这个细节在跨域或代理环境下特别容易翻车。
