因为模板在解析阶段被浏览器跳过，不执行脚本、不加载图片、不触发DOM生命周期，仅作静态占位符；真正可插件化需满足可注入、可初始化、可销毁三要素，并通过工厂函数与统一挂载/卸载契约实现。
为什么不能直接当插件用
因为内容在解析阶段就被浏览器跳过，不执行脚本、不加载图片、不触发任何 DOM 生命周期——它只是个静态占位符。你把它当成插件入口，结果页面空白、事件没绑定、样式没生效，不是代码写错了，是根本没启动。
常见误操作包括：innerHTML = tmpl.innerHTML覆盖容器（丢失表单状态）、cloneNode(true)复制含<script></script>的模板（脚本不执行）、在模板里写{{title}}（原生 HTML 完全不识别）。
真正能当“插件载体”的，必须满足三点：可注入、可初始化、可销毁。而只提供第一点，后两者全靠手写 JS 补齐。
如何让支持插件式动态加载
核心是把模板克隆 + 数据填充 + 初始化逻辑打包成一个可复用函数，并约定统一的挂载和卸载接口。这不是加个import就能完事的事，得设计契约。
立即学习“前端免费学习笔记（深入）”；
- 每个模板对应一个工厂函数，如
createCardPlugin()，返回带mount(el)和unmount()方法的对象 - 模板内用
data-plugin-init="tooltip"标记需要激活的子功能，JS 在mount()时查到并调用对应插件逻辑 - 禁止在模板里写
onclick="doSomething()"，所有交互绑定必须延迟到mount()阶段，否则多次挂载会重复绑定 - 如果插件需监听全局事件（如
resize），unmount()必须显式清理，否则内存泄漏
插件机制与 Web Components 的边界在哪
Web Components（如customElements.define('my-card', ...)）自带注册、升级、生命周期，但它是“硬注册”——一旦定义就全局可见，无法按需加载或卸载。而插件机制强调运行时调度，适合业务模块动态启用/禁用。
关键差异点：
-
customElements.define()只能调用一次，重复调用报错；插件系统允许loadPlugin('chart')和unloadPlugin('chart')来回切换 - Shadow DOM 隔离样式，但也隔离了
:focus-visible等系统级伪类，插件若依赖这些行为，得手动透传 - 插件传参用
data-props='{"theme":"dark"}'字符串解析，Web Components 用attributeChangedCallback响应属性变更，后者更实时但仅支持字符串 - SSR 场景下，Web Components 客户端 hydration 前为空白；插件系统可先渲染骨架 HTML，再异步加载逻辑，首屏更可控
构建插件系统时最容易被忽略的细节
不是怎么写插件，而是怎么判断它“真的就绪了”。很多人用document.scripts查脚本是否存在，但现代插件常用import('./plugin.js')动态加载，这个过程完全不产生<script></script>标签，document.scripts永远为空。
正确做法只有一条：等编辑器或宿主环境暴露的运行时标识。比如 TinyMCE 看editor.plugins.myPlugin是否为真值，Monaco 看monaco.languages.getLanguages().includes('sql')是否返回true，而不是轮询 DOM 或监听load事件。
另外，插件模块导出的必须是函数而非对象字面量——函数才能保证每次调用都获得全新实例，避免状态跨页面污染。
