预编译模板的兼容性问题本质是构建产物与运行时行为不匹配：vue3/react/svelte默认输出es2015+语法，需babel降级至es5并配polyfill；非原生标签（如）依赖框架解析，原生浏览器无视；ssr与csr dom结构不一致会导致hydration失败。
HTML 本身没有“兼容性问题”，但现代 JS 框架（如 Vue、React、Svelte）的预编译模板在浏览器运行时，会依赖特定的构建产物和运行时行为——这恰恰是兼容性分歧的真正来源。
预编译模板生成的代码是否能在旧浏览器运行
Vue 3 的 defineComponent + setup 语法、React 的 JSX 编译结果（如 React.createElement 调用）、Svelte 的 .svelte 文件输出，都默认生成 ES2015+ 语法（如箭头函数、解构、const/let）。这些在 IE11 或 Android 4.4 WebView 中直接报错 SyntaxError: Unexpected token 'const'。
- 必须通过构建工具（如 Vite、Webpack）配置
target或browserslist，显式降级到 ES5（例如启用@babel/preset-env） - Vue CLI 默认不支持 IE，需手动添加
transpileDependencies: ['vue'] - React 官方已放弃 IE 支持；若强需兼容，得用 React 16 +
react-app-polyfill，且不能用 Hooks（部分 Hook 在 IE 下无 polyfill）
HTML 标准标签与框架自定义元素的渲染差异
框架预编译模板常产出非标准 HTML 结构：Vue 的 <teleport></teleport>、React 的 <suspense></suspense>、Svelte 的 <slot></slot> 都不是原生 HTML 元素。它们依赖框架运行时解析，浏览器原生不识别。
- 直接把预编译后的 HTML 字符串塞进
innerHTML，这些标签会被当作普通内联元素处理，逻辑完全失效 -
<template></template>标签虽是原生 HTML5 元素，但 Vue/React 不直接用它做模板容器；它们通常把<template></template>当作静态占位符，靠 AST 解析提取内容 - 服务端渲染（SSR）输出的 HTML 若含框架专属指令（如
v-if、data-reactroot），客户端 hydration 时会校验结构一致性——不匹配就丢弃 DOM，重新挂载，导致 FOUC 或交互延迟
服务端吐出的 HTML 与客户端模板的语义冲突
当服务端已返回完整 HTML（含 SEO 内容），而 JS 框架又试图用预编译模板“接管”同一 DOM 区域，容易触发 hydration 错误或重复渲染。
- Vue 报错
Hydration failed because the server-rendered DOM，本质是 SSR 输出的 DOM 树与客户端模板编译后预期结构不一致（比如服务端没渲染某个条件分支，客户端却尝试 hydrate） - React 的
hydrateRoot要求服务端 HTML 必须由同版本 React 渲染，否则属性顺序、空格处理、事件绑定方式差异都会导致 mismatch - 避免方案：服务端只渲染骨架（
<div id="app"></div>），客户端全量接管；或严格对齐 SSR 与 CSR 的数据状态和模板分支逻辑
最易被忽略的是：预编译模板的“兼容性”不在语法层面，而在 hydration 生命周期和 DOM 树一致性上。哪怕代码能跑通，只要服务端 HTML 和客户端模板对同一数据的渲染结果有微小差异（比如日期格式、布尔属性存在性、空格折叠），就会破坏 SSR 优势，退化成纯客户端渲染。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
