html模板引擎是解决数据注入、安全转义和结构复用的基础设施，原生仅提供惰性dom容器，不支持变量替换、条件逻辑、默认转义或嵌套复用，须手动js补全且易xss。
HTML模板引擎在组件化开发中不是“锦上添花”的可选项，而是解决数据注入、安全转义和结构复用这三类硬性问题的基础设施。没有它，所谓“组件”往往只是复制粘贴的HTML片段，改一处漏十处；有了它，才能真正实现“定义一次、多处渲染、自动更新”。
为什么原生<template></template>标签不能直接替代模板引擎
原生<template></template>只提供“不渲染的DOM容器”，它不处理变量替换、条件逻辑或空值判断——这些都得靠手写JS补全，极易出错。
- 你不能在
<template></template>里写{{title}}或${item.name}，浏览器会原样显示，不会解析 - 想动态填入数据，必须手动调用
document.importNode()+querySelectorAll()+textContent = ...，一不小心就XSS - 没有默认转义机制：传入
<script>alert(1)</script>会直接执行，而html/template或Thymeleaf默认拦截 - 无法嵌套复用：一个页脚模板想引用“版权年份组件”，原生
<template></template>做不到，必须靠构建时或服务端拼接
html/template（Go）和Thymeleaf（Java）在组件化中的关键差异
两者都支持片段复用，但作用域、转义策略和调试体验完全不同，选错会卡在上线前最后一刻。
-
html/template用{{define "header"}}...{{end}}定义片段，{{template "header" .}}传入整个上下文对象；变量访问必须带点号{{.User.Name}}，空字段直接报错nil pointer dereference -
Thymeleaf用th:fragment="header"定义，th:replace="~{fragments::header}"引用；支持${user?.name}安全链式调用，更适合Java后端习惯 - 错误提示粒度不同：
html/template编译时报错位置精确到行号；Thymeleaf运行时报错常笼统为“Expression evaluation error”，需翻日志定位 - 构建集成方式不同：Go项目通常
go:embed模板文件，零额外依赖；Spring Boot需配置spring.thymeleaf.cache=false才能热更新
组件化模板中data-属性和slot的实际分工
前端组件化常混淆“配置驱动”和“内容投影”，结果导致模板既难复用又难维护。
-
data-属性适合传递简单开关或静态配置，比如data-variant="compact"控制卡片尺寸，data-closable="true"决定是否显示关闭按钮——这些值在服务端渲染时就已确定，不随用户交互变化 -
<slot></slot>是Web Components标准机制，用于运行时内容插入，比如<my-card><h3 slot="title">自定义标题</h3></my-card>；但它无法在服务端模板中使用，仅适用于JS驱动的Custom Element - 混合使用场景：服务端用
Thymeleaf渲染<div class="card" data-theme="${card.theme}">，前端JS再根据<code>data-theme加载对应CSS变量；而卡片正文区域留空，等JS接管后用<slot></slot>注入富文本 - 常见坑：
data-里塞JSON字符串（如data-config='{"color":"red"}'），易被单引号破坏结构；应改用JSON.stringify()并HTML实体编码
真正难的不是语法，而是决定哪些逻辑该交给模板引擎（比如菜单项是否显示）、哪些该留给客户端（比如点击后展开子菜单）。这个边界一旦划错，轻则重复渲染，重则首屏白屏或CSP拦截。
