直接用 .star--hover 会失效，因为评星组件的 hover 是父容器统一计算的连带效果，而非单颗星的独立状态；真实 hover 应绑定在 .rating 容器上，通过 :has() 或 JS 动态控制子元素。
为什么直接用 .star--hover 会失效？
BEM 的修饰符（modifier）本意是描述块的「状态变体」，但评星组件里用户交互是逐颗星触发的，.star--hover 如果写死在单个 上，就无法响应「鼠标移到第3颗星，前3颗都要高亮」这种连带效果。真实 DOM 结构里，hover 状态并不天然属于某颗星，而是由父容器统一计算得出。
- 真实 hover 逻辑必须绑定在包裹所有星星的容器上（比如
.rating），再通过 CSS 的:has()或 JS 动态加类控制子元素 - 若强行给每颗
单独加--hover，会导致 JS 需频繁增删多个类，且难以同步「只读态」「已选态」「半星态」等叠加状态 - Safari 15.4+ 才支持
:has(.star:hover)，旧版需降级用 JS 监听mouseover并设置data-hover-index="3"这类属性
如何让 .rating__star--selected 和 .rating__star--hover 共存不冲突？
BEM 不禁止多个修饰符共存，但 CSS 优先级和覆盖顺序必须明确。常见错误是把 hover 样式写在 selected 后面，结果 hover 时 selected 的颜色被覆盖。
- 修饰符类名应按「稳定态 → 临时态」排序：先写
.ratingstar--selected，再写.ratingstar--hover，确保 hover 能叠加覆盖 - 更稳妥的做法是用属性选择器隔离：用
[data-state="hover"]控制 hover，[data-state="selected"]控制选中，避免类名堆叠带来的权重混乱 - 如果支持 CSS 自定义属性，推荐用
--star-fill: #ffc107统一控制颜色，hover 和 selected 分别设置不同值，由同一组基础样式消费
readonly 模式下，为什么 .rating--readonly .rating__star--hover 不生效？
因为 .rating--readonly 是块级修饰符，它只影响自身容器行为，而默认 hover 样式往往写在 .rating__star:hover 这种伪类上——伪类优先级高于普通类，且不继承父级修饰符。
- 必须显式写出禁用规则：
.rating--readonly .rating__star:hover { pointer-events: none; }，否则鼠标移入仍会触发原 hover 效果 - 更干净的解法是完全剥离伪类，改用 JS 控制：只在非 readonly 时绑定事件，并动态添加
.rating__star--is-hovering类；readonly 下这个类永远不出现 - 注意：iOS Safari 对
pointer-events: none在部分 inline 元素上支持不稳定，建议对.rating__star使用display: inline-block或display: block保证兼容
BEM 在评星组件里真正难的不是命名，而是状态归属——哪部分该由块管理（如 hover 范围），哪部分该由元素自身承载（如 disabled、focused）。一旦把「当前悬停到第几颗」这种跨元素状态塞进单个 .star--hover，后续扩展半星、键盘导航、ARIA 属性都会变得牵强。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
