bem类名必须严格手写或工具生成，因其通过block__element--modifier结构强制表达作用域边界；漏连字符、嵌套过深或拼写错误即失效，导致样式冲突与维护失控。
大型项目里 CSS 维护难，根本不是写得不够快，而是改一处、崩三处——类名冲突、变量散落、样式隐式依赖、新人看不懂结构。工具本身不解决问题，但用对了能卡住常见错误入口。
为什么 BEM 类名必须严格手写或靠工具生成
BEM 不是“多打几个下划线”，而是用命名强制表达作用域边界。一旦写成 .button--primary 却漏掉双连字符，或者写成 .card__header__title（嵌套两层 Element），就等于放弃隔离能力。
- 常见错误现象：
!important越来越多、审查元素时发现样式被远在components/modal/modal.less里的同名.button覆盖 - JS 操作类名必须完全匹配：
el.classList.add('user-card__avatar--loading')，别拼'user-card__avatar' + '--' + state，容易少个连字符或大小写错 - VS Code 配
PostCSS BEM插件或自定义 snippet，比靠人盯更可靠；Webpack/Vite 项目里建议用postcss-bem在编译期校验类名格式
Less 变量和 Mixin 怎么避免“越用越乱”
变量不是往 variables.less 里堆颜色就行。真正卡点在于：谁改、谁用、改了影响谁，得有可见路径。
- 变量命名必须带语义：
@color-text-primary，而不是@blue-500；后者在设计系统换色后立刻失效 - Mixin 必须纯样式化、参数化：
.flex-center()可以，但.card-style()这种包裹整块选择器的写法会锁死结构，调用方无法覆盖内部某条规则 - 禁止在组件文件里重定义同名变量——Less 不报错，但导入顺序决定最终值，调试时根本看不出哪一层覆盖了哪一层
为什么 index.less 文件不能省，也不能乱写
index.less 是模块的“对外接口”，不是偷懒的汇总文件。它唯一任务是声明本模块的依赖关系和导出内容。
- 错误写法：
pages/dashboard.less直接@import "../../components/button/button.less"—— 一旦button内部重构、拆分文件，这里立刻报Undefined mixin - 正确写法：每个模块根目录放
index.less，只写三行：@import "variables"; @import "mixins"; @import "button";；业务页只@import "../index" - 根目录
styles/index.less按层级顺序导入：@import "base/index"; @import "components/index"; @import "pages/index";，顺序错了，@color-text-primary可能还没定义就被用了
真正卡住维护滑坡的，从来不是某个工具没装，而是变量谁都能改、类名谁都能乱写、index.less 谁都敢跳过——这些地方没有机器约束，全靠人自觉，迟早崩。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
