Hover 和 Active 状态需显式声明并统一用 Mixin 管理，避免嵌套错误与 IE11 兼容问题；移动端必须单独处理 &:active；参数命名应体现用途，交互状态须平级书写并逐项验证。
Hover 和 Active 状态写在一起容易漏掉 &:active 伪类
Less 中用嵌套写 &:hover 很顺手，但人眼容易忽略 &:active —— 尤其在移动端，点击反馈没触发，用户会觉得按钮“没反应”。这不是浏览器兼容问题，是书写习惯导致的遗漏。
实操建议：
- 把交互状态统一收进一个 Mixin，强制覆盖所有常见状态
- 不要只写 &:hover，&:active、&:focus、&:focus-visible 都得显式声明
- 移动端需额外加 &:active（iOS Safari 对 :hover 支持弱，且无悬停概念）
示例：
.interactive-states(@hover-bg: #007bff, @active-bg: #0056b3) {
&:hover {
background-color: @hover-bg;
}
&:active {
background-color: @active-bg;
}
&:focus {
outline: 2px solid rgba(0, 123, 255, 0.25);
}
}
调用时直接 .interactive-states(#e9ecef, #dee2e6)，避免每次手动补全。
Mixin 参数命名要区分“视觉变化”和“行为意图”
写成 .hover-bg(@color) 看似简洁，但实际项目里常遇到：同一个按钮在 hover 时变色，在 active 时不仅变色还要压扁阴影、缩小边框——此时单靠颜色参数撑不住。
实操建议：
- 参数名体现用途，比如 @hover-transform、@active-box-shadow，别用 @hover-style 这种模糊词
- 对需要降级的属性（如 transform），Mixin 内部加 transform: none; 回退兜底
- 避免把 transition 写死在 Mixin 里；不同组件过渡节奏不同，应由调用方传入 @transition 参数控制
嵌套层级过深导致 &:hover &:active 语义错误
Less 嵌套时如果多写了一层 &，比如：
&:hover {
&:active { ... }
}
实际编译出的是 .btn:hover .btn:active（子元素匹配），而非预期的 .btn:hover, .btn:active 或同时生效的复合状态。这是最隐蔽的 CSS 逻辑错位。
实操建议：
- 所有交互状态都平级写在选择器一级，用逗号分隔或独立声明
- 如果真需要“悬停时再点击”的复合效果（比如菜单展开后点击子项），改用 JS 切换 class，别依赖伪类嵌套
- 开发时打开浏览器开发者工具，检查生成的选择器是否符合直觉，尤其注意空格和 & 的位置
IE11 下 :focus 和 :active 行为不一致，Mixin 要做条件处理
IE11 不支持 :focus-visible，且 :active 在键盘操作（空格/回车）时不会触发，只响应鼠标按下。这意味着仅靠一套 Mixin 无法覆盖所有可访问场景。
实操建议：
- 用 .for-ie11() 条件 Mixin 包裹 IE 专属规则，比如给 :focus 加更粗的 outline
- 不要用 &:active 替代键盘焦点反馈；必须保留 &:focus 并确保它足够明显
- 如果项目已放弃 IE11，就在构建流程中加注释标记，比如 // IE11: not supported，避免后续接手的人误以为要兼容
样式逻辑越靠近用户交互，就越容易被“看起来正常”骗过去。hover 动效流畅不代表 active 反馈可靠，focus 样式存在也不代表键盘用户能顺畅操作——这些都得拆开验证，不能靠 Mixin 一包了之。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
