bootstrap类名必须严格使用kebab-case（如.container-fluid），响应式断点仅支持xs/sm/md/lg/xl/xxl，.visible-类在v5中已废弃，改用.d--none等；命名体系协作友好但缺乏演进退出机制。
类名必须用 kebab-case，不能用 camelCase 或 PascalCase
Bootstrap 所有预设类名都强制使用短横线分隔（kebab-case），比如 .container-fluid、.btn-primary、.col-md-6。这不是风格偏好，而是框架内部 CSS 选择器和 JavaScript 组件逻辑的硬性依赖。
常见错误是写成 .containerFluid 或 .btnPrimary —— 这类写法在 HTML 中完全无效，浏览器根本不会匹配到任何样式规则。
- JS 组件（如
Dropdown、Modal）初始化时也靠 class 名触发，写错就等于禁用功能 - 自定义扩展时，如果混用
camelCase类名，后续维护者极难分辨哪些是 Bootstrap 原生类、哪些是你写的 - 构建工具（如 PostCSS、PurgeCSS）依赖标准命名做 tree-shaking，非标准写法可能导致误删或冗余保留
响应式断点前缀必须严格对应内置断点值
Bootstrap 的响应式类不是随便加个 sm 或 xl 就生效，它只认框架定义的断点别名：xs、sm、md、lg、xl、xxl（v5.3+）。写成 .col-mid-4 或 .d-tablet-none 不会触发任何响应行为。
断点类还隐含“最小宽度”语义：.d-md-none 表示「在 md 及更大视口下隐藏」，不是「仅在 md 下隐藏」。这点常被误解，导致媒体查询逻辑错乱。
- v4 和 v5 的断点数值不同（例如 v4 的
lg是 ≥992px，v5 是 ≥992px 但xl起点从 1200px → 1400px），升级时需核对$grid-breakpoints变量 - 自定义断点必须通过 Sass 变量重写，不能仅靠新增 class 名——否则 JS 组件（如栅格重排逻辑）无法感知
-
.visible-*类在 v5 中已被移除，改用.d-*-none/.d-*-block等，沿用旧名会导致样式彻底失效
组件类名层级深、语义弱，定制成本高
Bootstrap 的类名设计优先保证功能覆盖而非语义表达，比如 .dropdown-menu-dark 描述的是外观效果，而不是“导航菜单的暗色变体”。这种命名让 HTML 很快变成一堆视觉修饰符堆砌，可读性下降明显。
当项目需要统一修改某类交互元素（比如所有下拉菜单的圆角、阴影、过渡时间），你得同时改 CSS、JS 初始化逻辑、甚至 HTML 结构里的 class 组合——因为样式分散在多个 class（.dropdown、.dropdown-menu、.dropdown-item）中，没有单一语义锚点。
- 想局部覆盖按钮样式？不能只改
.btn，还得处理.btn-primary、.btn-sm、.btn-outline-secondary等组合态 - 用 CSS-in-JS 或 Tailwind 后再回看 Bootstrap 类名，会觉得冗余感极强——每个 class 都像在重复声明“这是按钮”“这是大号”“这是蓝色”
- 无障碍（a11y）相关 class（如
.sr-only）虽实用，但名字本身不带上下文，团队新人容易误用为通用隐藏手段
命名体系对协作友好，但对长期演进不友好
统一命名确实降低了多人协作门槛：前端不用猜后端给的 class 是不是 Bootstrap 原生类，设计师也能快速查文档确认 .form-control 对应什么样式。但这也锁死了演化路径——一旦项目规模扩大、设计系统独立，Bootstrap 的 class 名就成了技术债锚点。
比如你想把 .card 改成更语义化的 .product-summary，就得同步改 JS 初始化、重写所有依赖 .card-body 的 CSS、并确保第三方插件（如图表库的 tooltip 定位）不受影响。实际中往往选择“将就”，最后页面里混着 .card 和 .product-card-wrapper 两种命名体系。
真正容易被忽略的是：Bootstrap 的命名规范本身不提供“退出机制”。它没定义如何平滑过渡到自定义命名，也没提供 class 映射层（类似 Vue 的 v-bind:class 动态映射）。这意味着，只要还在用它的 CSS 文件，你就得按它的规则写 HTML。
