HTML模板引擎是服务端/构建时文本处理工具，通过占位符与数据拼接生成安全HTML，解决XSS防护、结构与逻辑解耦、复用及SSR等原生HTML无法实现的问题。
HTML模板引擎不是一种语言，也不是浏览器内置功能，而是一个运行在服务端（或构建时）的文本处理工具：它把写死的HTML结构 + 占位符（比如 {{name}}、{{.Title}}、th:text="${user.name}"）和真实数据拼在一起，生成最终可被浏览器直接解析的HTML字符串。
它解决的核心问题很实际：避免用字符串拼接写HTML，防止XSS漏洞，让前端结构和后端数据解耦，支持复用（如页头、分页组件）、国际化、条件渲染和循环列表——这些靠原生HTML做不到。
为什么不能直接用 document.write() 或 JS 拼 HTML？
-
document.write()在页面加载完成后调用会清空整个文档，早已被弃用； - 前端JS拼HTML（如
innerHTML = '<div>' + name + '</div>'）极易触发XSS，且逻辑和结构混在一起，改个class要翻三处代码； - 没有编译期检查：少个括号、错个变量名，只有运行时白屏或报错
Cannot read property 'name' of undefined； - 无法服务端预渲染（SSR），首屏慢，SEO不友好。
常见模板引擎的语法差异到底影响什么？
不同引擎只是“怎么写占位符”的约定不同，但背后的数据绑定机制、转义规则、作用域处理差别很大：
-
html/template（Go）：默认全转义，{{.Name}}安全；想不转义得显式写{{.RawHTML | safeHTML}}； -
Thymeleaf（Java/Spring）：属性式语法th:text="${user.name}"，保留HTML可浏览器直开，但必须加th:fragment才能复用； -
Freemarker：用${user.name!}表示空值默认为空字符串，<#if user??>...</#if>判断存在性，语法更贴近传统脚本； -
Handlebars（JS）：无默认转义，{{name}}会执行HTML，危险；安全写法是{{{name}}}（三个大括号）才不转义，容易搞反。
参数传错、忘记判空、该转义没转义——这些不是“写法习惯问题”，而是上线后直接导致内容错乱或被注入脚本。
立即学习“前端免费学习笔记（深入）”；
模板文件怎么组织才不容易失控？
放任所有模板平铺在 templates/ 下，三个月后没人敢动 index.html，因为不知道它引用了哪个 partial、依赖哪些数据字段。
3x-ui 的目录结构是个务实参考：
-
common/page.html：定义骨架，用{{template "content" .}}插入子内容； -
component/aClientTable.html：只负责渲染一张客户端列表，接收.Clients数据，不碰路由或权限； -
form/protocol/vless.html：协议配置表单按协议类型拆，避免一个500行的settings.html。
关键不是“分得细”，而是每个模板文件只做一件事，且通过明确的入参契约（比如必须传 .Title 和 .Items）来约束使用方式。
真正难的从来不是“怎么让变量显示出来”，而是当运营半夜要求首页加一个AB测试横幅、同时兼容新老用户数据格式、还要保证SEO抓取到正确标题时，你能不能在不改三处逻辑、不引入新bug的前提下，两分钟内完成上线。模板引擎的价值，就藏在这种确定性里。
