HTML模板非原生语法，而是Vue、Angular等框架在编译或运行时对字符串/AST做的语法转换，v-if、{{}}等均非HTML标准，脱离框架即失效。
HTML模板不是原生语法，而是框架层抽象
浏览器本身不解析 v-if、{{ }} 或 ngFor 这类写法——它们根本不是 HTML 标准的一部分。所谓“HTML 模板”，实际是 Vue、Angular、React（JSX）等框架在编译或运行时对字符串/AST 做的语法转换。你写的 <div v-if="show">...</div>，最终被 Vue 编译器转成 render 函数调用，和原始 HTML 无关。
容易踩的坑：
- 直接把带
v-model的模板丢进innerHTML里，它只会当纯文本渲染，指令完全不生效 - 用
document.querySelector查找v-for渲染出的元素，可能查不到——因为 DOM 是运行时动态生成的，不是模板字符串静态存在的 - 服务端返回含
{{ user.name }}的 HTML 片段，若没走 SSR 流程，前端框架不会自动接管，结果就是页面上真显示{{ user.name }}
语法糖 ≠ 语法，别混淆编译时与运行时
像 Vue 的 v-bind: 缩写为 :、v-on: 缩写为 @，本质是编译器识别的 token 替换规则，不是浏览器理解的语法。同样，React 的 JSX 中 className 替代 class，是因为 JS 对象属性不能用关键字，必须转义。
关键差异点：
立即学习“前端免费学习笔记（深入）”；
-
v-bind:href="url"和:href="url"在 Vue SFC 中等价，但若你用原生DOMParser解析该字符串，两者都会被当作普通属性保留，无任何绑定行为 -
data-*属于合法 HTML5 自定义属性，浏览器原生支持读写；而v-前缀全靠框架解析，脱离框架即失效 - 模板中写
<mycomponent></mycomponent>看似像 HTML 标签，实则是 JSX 或 Vue SFC 的组件注册机制，不是 HTML 元素，也不能用document.createElement('MyComponent')创建
工程化中模板语法糖的真实成本
语法糖降低的是人眼阅读负担，但会增加构建链路复杂度和调试路径长度。比如一个 v-for 渲染异常，你得先确认：是响应式数据没更新？是 key 冲突？是 template 编译阶段报错？还是 runtime 的 patch 逻辑出问题？
常见陷阱：
- Vue 3 的
<template v-for></template>必须显式加key，否则警告且渲染错乱；而 Vue 2 允许省略，升级时容易漏改 - Angular 的
*ngIf是结构型指令，会销毁/重建 DOM；而[hidden]只是 CSS 切换，性能和状态保持完全不同 - Webpack 的
html-webpack-plugin注入变量用的是，和 Vue 模板语法冲突，需手动转义或换用html-loader
什么时候该放弃模板语法糖
当项目规模小、交互简单、团队无框架经验，或需要强 SEO/首屏直出时，硬套模板语法糖反而拖慢交付。纯 HTML + fetch + innerHTML 手动拼接，有时比配一套 Vue CLI 更快更可控。
可考虑裸 HTML 的场景：
- 营销页、活动页、邮件模板——内容静态为主，JS 仅做表单提交
- 微前端子应用中作为基座通信桥接层，避免框架版本冲突
- Web Components 封装的自定义元素，内部用
template.innerHTML+cloneNode，不依赖框架生命周期
语法糖的价值不在“写起来短”，而在“团队共识成本低”和“生态工具链成熟”。但一旦脱离这个前提，它就只是多一层需要解释的抽象。
