深入理解：揭开被误读的基础组件面纱
不少开发者初次接触标签时，往往误以为它能像Vue组件一样直接构建完整的组件化架构。然而，它并非一个“面向未来的组件化架构”解决方案——它仅仅是浏览器最底层的原生组件化基础设施。决定架构能否长期稳定运行的关键，在于围绕它设计的数据绑定逻辑、样式隔离策略以及复用协议。
为何
浏览器的处理机制十分直接：它会跳过内部的解析，脚本不会执行、图片不会加载、CSS也不生效。最常见的错误是把当作Vue组件来编写，结果渲染时发现DOM区域空空如也。
还有一个更易踩坑的细节：使用cloneNode(true)会丢失这类状态，而通过innerHTML = tmpl.innerHTML则可能破坏表单控件的初始值。真正能保留状态并兼容Shadow DOM的正确克隆方式，只能是document.importNode(tmpl.content, true)。如果没有彻底理解这一点，后续的组件化开发过程将充满艰辛。
如何为
纯HTML并不识别{{title}}这类插值语法，必须依靠JavaScript进行显式替换。但直接使用node.textContent = data.title或node.innerHTML = data.content会带来XSS风险，尤其是后者，可能随时演变为安全漏洞。
- 只有对于完全可信的字段（例如配置项、枚举值）才使用
textContent - 处理富文本内容时，先用
DOMPurify.sanitize()进行过滤，再赋值给innerHTML - 避免在模板中硬编码ID（如
id="card-1"），多次实例化会导致ID重复，进而引发querySelector和CSS选择器混乱 - 绑定节点统一采用
data-bind="title"属性，不要依赖class名称——否则调整样式时极易误删绑定逻辑，留下长期隐患
另外建议：当模板需要多次实例化时，最好动态生成唯一ID，防止同一页面出现重复ID。这些细节往往直接决定组件库的可维护性。
什么时候应该从
当出现以下任一场景时，意味着“ + 手动JS”的组合已经触及能力边界：
- 需要响应属性变化（例如
attributeChangedCallback仅在Custom Element中生效 - 多个页面共用同一组件，且需要独立的样式作用域——
无法阻止全局CSS泄漏，Shadow DOM成为刚需 - 组件内需要监听点击、输入等事件，又不希望污染全局
document——Custom Element的this.shadowRoot.addEventListener()提供了天然的作用域隔离 - 需要SSR支持或hydration行为——
是纯客户端方案，服务端无法处理
结论非常清晰：真正面向未来的前端架构，并非纠结于选择还是Custom Elements，而是需要清楚每项技术不可替代的定位。用处理轻量、低频、静态内容的复用；用Custom Elements封装带状态、需要交互、跨环境一致的UI单元。一旦混淆两者的边界，架构的复杂度就会彻底失控。
