HTML 本身无法动态生成页面，必须依赖 JavaScript 操作 DOM 或模板引擎（如 Handlebars、Jinja2）及服务端语言；浏览器端需预编译与数据绑定，服务端需防 XSS 与路径遍历，零依赖方案可用 template 标签与 DOMParser。
直接用原生 HTML 写动态页面是不可能的——HTML 本身不执行逻辑，必须靠外部工具注入数据。真正在浏览器里“生成动态页面”的，只有 JavaScript 操作 DOM 或配合模板引擎编译；服务端生成则依赖 Python、Node.js、Go 等语言的模板系统。
浏览器端：用 html-loader + Handlebars 预编译模板
Webpack 项目中，html-loader 能把 .hbs 文件转成可执行函数，适合构建时确定结构、运行时填数据的场景。
- 安装命令必须带
--save-dev：npm install html-loader handlebars --save-dev - Webpack 配置里
preprocessor函数返回的是已渲染字符串，不是模板函数——别漏掉require('handlebars').compile(content)(data)这层调用 - 如果模板里有
<img src="logo.png">，html-loader默认会尝试解析路径；若想保留原始字符串（比如要 runtime 动态拼接），得加esModule: false和sources: false选项 - 错误现象：
Uncaught ReferenceError: Handlebars is not defined——说明没在全局注入 Handlebars，或用了import但没配置expose-loader
服务端：Python 用 Jinja2 安全填充数据
Jinja2 是最稳妥的选择，自动转义变量，防 XSS，且语法简洁。它不依赖框架，纯 Python 脚本也能跑。
- 模板里写
{{ user.name }}是安全输出，写{{ user.bio | safe }}才跳过转义——除非你 100% 确认bio不含用户输入，否则别加| safe - 不要用字符串拼接组装模板路径：
template_env.get_template('user/' + request.args['type'] + '.html')是严重路径遍历漏洞，应白名单校验或用select_template() - 批量渲染大量数据时，避免在模板里写
{% for item in items %}...{% endfor %}嵌套多层逻辑，把预处理逻辑提到 Python 层，模板只负责展示 - 常见错误：
TemplateNotFound多因loader路径没设对，建议用FileSystemLoader('./templates')显式指定，别依赖相对路径
零依赖方案：用 template 标签 + DOMParser 运行时克隆
不引入任何构建工具或后端，也能实现轻量动态渲染。核心是浏览器原生的 <template> 元素和 DOMParser 解析 HTML 字符串。
立即学习“前端免费学习笔记（深入）”；
- 把模板写在
<template id="item-row"><tr><td>{{id}}</td></tr></template>里，用document.getElementById('item-row').content.cloneNode(true)拿到文档片段 - 替换占位符别用正则全局匹配：
innerHTML.replace(/{{\s*(\w+)\s*}}/g, (_, key) => data[key])——容易误伤 HTML 属性或注释，优先用querySelectorAll('[data-bind]')绑定 -
DOMParser解析字符串时，若内容含<script>，默认不会执行；但若用innerHTML直接赋值，脚本会执行——这是关键安全分界线 - 性能陷阱：每次渲染都
new DOMParser().parseFromString(html, 'text/html')开销大，应缓存解析后的Document对象或改用template.content
最容易被忽略的是上下文隔离：前端模板渲染的数据，和服务端传来的 JSON 结构必须严格对齐；而服务端模板（如 Jinja2）里的过滤器（| upper）、测试器（is defined）在前端不可用，混用会导致渲染失败或空内容。别指望同一套模板文件前后端通用，除非你用的是同构框架（如 Next.js）。
