--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 当作万能状态开关，后续维护者很难分辨哪些活跃态是约定俗成的、哪些是临时逻辑的、哪些该由服务端决定——这种模糊性会在半年后某个深夜上线前暴露得最彻底。