--active是BEM修饰符，用于声明组件固有活跃变体（如导航项选中态），应静态存在于HTML中；is-active是JS驱动的状态类，专用于动态切换且需降级安全的场景（如侧边栏开关），二者须职责分离、不可混用。
--active 是修饰符，不是状态类；它只用于声明“这个块/元素天然支持活跃变体”，不适用于 JS 动态切换的临时反馈。
什么时候该用 --active 修饰符
它表达的是组件设计层面的固有变体，而非运行时状态。比如导航项默认就存在“当前选中”这一语义角色，.nav__item--active 表示“这是被设计为当前项的那个实例”，HTML 中可静态存在，CSS 可独立定义样式，无需 JS 干预。
- 适用场景：菜单项、标签页标题、按钮组中的选中项（单选模式）、评分组件中被用户点中的星
- 关键判断：这个“活跃”是否在组件文档或设计稿里被明确定义为一种可复用的视觉/语义变体
- 反例：侧边栏开关、下拉面板展开态、轮播图当前页指示器——这些依赖 JS 控制且可能 SSR 失效，不该用
--active
为什么不能用 --active 做 JS 切换的状态反馈
因为 BEM 的修饰符是静态契约，而 JS 驱动的状态是动态事实。强行混用会导致三类问题：
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- CSS 规则失效：若 JS 没加载或执行失败，
.block--active类缺失，页面直接丢失关键样式，无降级路径 - 语义混淆：
.select__option--active看似表示“当前高亮选项”，但键盘聚焦、悬停、多选等场景会与之冲突，无法区分“焦点”“选中”“悬停”三种逻辑 - 跨组件不可读：路由、表单校验、A11y 工具无法识别
--active是状态还是变体，is-active才是通用状态信号
--active 和 is-active 能否共存
能，而且推荐——但必须职责分离：
-
.tabs__item--active控制文字加粗、底边框、padding 微调等视觉细节 -
.tabs__item.is-active仅作为 JS 查询依据、A11y role="tab" 的 aria-selected="true" 同步信号、以及外部模块（如 analytics）的钩子 - CSS 中必须同时写
.tabs__item--active.is-active或分开定义，避免仅靠is-active导致视觉无变化
评分组件中 --active 的典型误用
常见错误是给每颗星单独加 .rating__star--active 并靠 JS 切换。这会破坏两个关键点：
- 状态归属错位：活跃态属于整个
.rating块（用户已完成选择），不是某颗星的固有属性 - 交互耦合：鼠标滑过第 3 颗星时，需高亮前 3 颗，但
--active无法动态批量控制；正确做法是监听.rating的mousemove，动态添加.rating__star--hovered类 - 禁用处理失效：若
.rating--readonly生效，所有.rating__star应忽略 pointer-events，此时再操作--active类已无意义
真正容易被忽略的点在于：BEM 的修饰符不是“JS 加 class 的快捷方式”，它是设计语言在代码里的映射。一旦把 --active 当作万能状态开关，后续维护者很难分辨哪些活跃态是约定俗成的、哪些是临时逻辑的、哪些该由服务端决定——这种模糊性会在半年后某个深夜上线前暴露得最彻底。
