HTML模板实现组件样式复用基类
HTML模板中应使用class而非id实现样式复用，因为id只能唯一标识元素。模板复用不等于样式复用，需单独维护CSS类体系并确保样式文件引入。推荐语义化class结合CSS自定义属性与@layer分层，避免内联样式和硬编码。
id 的唯一用途是标识一个元素，类似于身份证，它并非为样式复用而设计。很多开发者起初觉得“功能上也能用”，但实际踩过坑之后，就会明白为什么更推荐使用 class。
为什么不应使用 id 作为样式复用基类
先看一个简单问题：如果将同一个 id 应用于多个元素，document.getElementById() 只会返回第一个匹配项，后续元素将无法通过 JavaScript 获取。这仅仅是冰山一角。无障碍工具会报错，CSS 选择器的表现也会变得不可预测，尤其是当结合 :focus-within 或 label[for] 等属性时，行为可能完全偏离预期。
更麻烦的是，如果写了一个 #card { padding: 1rem; }，而页面中有 5 个 id="card"，样式只会对第一个生效。其余元素看起来就像没有样式一样，但很难第一时间意识到是 id 冲突——它不会报错，也不会发出警告，就这样安静地带来问题。
class天生为复用而设计，可以重复、组合、叠加- 语义化类名如
card、btn、form-field才是真正可继承的基类起点 - 脱离标签名和层级来定义基类（例如
article h2），一旦结构调整，样式链条就会断裂
这引出一个关键认知：模板复用不等于样式复用。需要单独维护一套可复用的 CSS 类体系，并确保所有使用该模板的地方都引入了对应的样式文件或内联样式块。 核心思路非常朴素：将 class 视为一份契约。模板声明“我需要 具体落地方法： 最典型的翻车场景是：本地开发一切正常，部署到线上后，部分卡片缺少边框、文字没有行高、按钮丢失圆角。排查后才发现，构建流程遗漏了某份 CSS 文件，或者 CDN 缓存了旧版样式表。模板本身不会给出任何报错提示——它只是安静地渲染出一堆没有样式的 div。 这暴露了一个残酷的事实：HTML 模板不校验样式是否存在。它只负责结构，不负责视觉。因此，样式复用必须依赖人工约定和工程约束来兜底，例如在 CI 中检查 class 是否在 CSS 中有定义。 最容易被忽略的场景是什么？多个团队共用同一套模板时。如果没有人更新 标签只有一个作用：定义 DOM 片段。它不会解析、不会渲染、也不会自动应用样式。因此，不能指望在其中放入 .card 的定义。
container 可能根本没有定义
scoped 策略（如 Shadow DOM），但原生 不支持此功能如何让模板中的 class 成为可继承的样式基类
.card、.card-title 这些类存在”，样式层负责兑现。不是模板驱动样式，而是样式驱动模板行为。
--card-padding: 1rem;，然后在 .card 中通过 padding: var(--card-padding) 引用@layer 显式分层，基类放在 @layer base，组件变体放在 @layer components，从而避免权重冲突element.style.color = '#333'——这会导致覆盖所有 CSS 变量和媒体查询var(--color-primary) 实现，绝不用硬编码常见错误：以为将 HTML 放入
就能自动获得样式复用能力.card-footer 的 CSS，但新业务向模板中加入了