模板化减少语法错误却掩盖语义缺陷：W3C验证器无法发现导航重复、标题跳级等结构性问题，必须依赖人工判断层级意图与数据契约校验。
模板化会让 HTML 语法错误变少，但掩盖更危险的语义缺陷
模板本身不校验语义，只保证结构拼接不出错。你用 v-for 渲染 10 个 <nav></nav>，工具不会报错，但语义上一个页面只能有一个主导航——这种错误 W3C 验证器也抓不到，只能靠人工判断层级意图。
常见错误现象：<div class="header"> 被模板批量生成，替换成 <code><header></header> 却没同步改 CSS 选择器，结果样式全崩；或 <button></button> 在模板里漏写 type 属性，上线后表单内点击意外提交。
- 使用场景：组件化框架（Vue/React）中，模板负责结构，但语义责任仍落在开发者手上
- 参数差异：Svelte 的
<slot>和 Vue 的slot传入内容时，若父级没约束aria-label必填，子模板就可能产出无障碍缺陷 - 性能影响：构建时内联模板（如 Vite 插件）输出纯 HTML，比运行时
fetch()加载片段快且无 CSP 风险
可维护性提升明显，但依赖“模板作者”的设计意识
模板能消灭复制粘贴导致的漏改问题，比如页脚版权年份、统一 data-section 属性。但前提是模板本身没把逻辑耦合进去——比如在模板里写 class="{{ user.role === 'admin' ? 'super-btn' : 'normal-btn' }}"，等于把业务判断塞进 HTML，后期想加权限分级就得动模板，而不是改 JS 数据。
容易踩的坑：
立即学习“前端免费学习笔记（深入）”；
- 硬编码 class 名：模板里出现
red-btn或big-title，换主题时得全局搜替换，而非改 CSS 变量 - id 重复：循环渲染卡片时用
id="card-{{ index }}"，但 JS 里写死document.getElementById('card-0')，实际只取第一个 - for/id 不配对：模板生成
<label for="email"></label>，但输入框是<input id="user-email">，表单可访问性直接失效
SSR 和客户端渲染混用时，模板最容易暴露运行时脆弱性
模板在构建阶段静态展开很稳，一旦掺进运行时逻辑（比如用 innerHTML 动态插入模板片段），就会触发 DevTools 里高频出现的 TypeError: Cannot read property 'xxx' of null——因为 JS 执行时 DOM 还没就位。
典型场景：
- 模板含
document.querySelector('.js-toggle')内联脚本，但没加defer或包裹在DOMContentLoaded - Next.js 页面里模板调用
window.location.href，服务端渲染时报ReferenceError: window is not defined - 用
<template>标签存片段，但忘记用document.importNode(template.content, true)克隆，直接 append 导致后续复用时 DOM 引用丢失
真正卡住质量的，从来不是模板语法，而是数据契约是否清晰
一个高质量模板，必须明确声明它需要什么字段、类型、默认值、是否必填。比如卡片模板要求传入 title（string）、imageSrc（string，非空）、alt（string，不可为 "" 除非配 role="presentation"）。没这层契约，模板再漂亮，产出的 HTML 也可能 alt 缺失、链接 href 为空、ARIA 属性错位。
复杂点在于：契约往往藏在文档注释或 props 类型定义里，没人看；而 HTML 模板本身又不强制校验——alt="" 能跑，但读屏器会跳过整张图。这点比任何语法错误都难被 CI 工具捕获，只能靠 Code Review 时盯住每个传入字段的实际用途。
