缩写类名会直接切断调试链路，不该缩写；仅btn、txt、img、cnt四类在满足全团队统一、高频出现、全场景一致三个硬条件下勉强可接受；modifier中缩写更危险，应使用card--compact等语义化命名。
缩写类名会直接切断调试链路
不该缩写。缩写 user-card__avatar--large → user-card__avt--lg 后，DevTools 里看到 avt 不知道是 avatar、activity 还是 alert；全局搜索 avt 可能误中 notification__avt-badge 和 activity__avt-icon；IDE 补全也失效——user-card__a 可能匹配到 action、alert、avatar，但 user-card__avatar 是唯一确定的。
哪些缩写勉强可接受？必须满足三个硬条件
仅 btn、txt、img、cnt 这四类在极少数项目中可考虑，且必须同时满足：
- 全团队长期统一使用（不是某人临时起意）
- 对应单词在项目中高频出现（如
title出现在每个 Block 中） - 所有文档、口头沟通、代码注释都用同一缩写指代
不满足任一条件就禁用：usr（user 无歧义、长度可接受）、ctn（container 太泛，card__ctn 分不清是 content 还是 container）、ttl（title 缩写虽常见，但一旦混入 tooltip 就立即歧义）。
Modifier 里缩写比 Element 更危险
card--sm 看似省事，但它不回答“这个状态意味着什么”：sm 是 small？summary？smart？而 card--compact 或 card--condensed 直接表达设计意图。更糟的是堆叠时：btn--p-sm--d-true--v-outline vs btn--primary--disabled--outline，前者 JS 切换、CSS 调试、Code Review 全部降噪。
Modifier 必须是离散、互斥、可枚举的语义值，不是尺寸或颜色的具体值。尺寸交给 CSS 自定义属性：<button class="btn" style="--btn-size: 14px"></button>，类名保持干净。
真正该动刀的地方从来不在字母数上
类名变长只是表象，根因是组件边界模糊、状态外溢、职责错位。比如 user-profile__avatar--size-lg--theme-dark，问题不在字符数，而在于 avatar 不该承载页面级主题或跨场景尺寸。此时该做的是：
- 把
status-badge从user-card__status提级为独立 Block - 用
dashboard--is-loading统一控制多个子元素的加载态，而非给每个__element加--is-loading - 把
--size-lg这类值型配置抽成style="--avatar-size: large"，保留user-profile__avatar的纯粹语义
每次写新类名前没问“它是否具备自身状态、行为或复用场景”，就直接塞进父 Block 的 __ 下，类名只会越来越长，组件却越来越难抽离。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
