BEM在音视频UI中是功能正确性的前提，而非可选风格；video-player__progress等控件必须强绑定播放器上下文，禁用通用类名以避免样式污染、JS失效与状态不同步。
直接套用通用类名（如 .slider、.btn）或混用 video-player 和 hero-video 块，会导致样式污染、JS 控制失效、状态不同步——BEM 在音视频 UI 中不是“可选风格”，而是功能正确性的前提。
为什么 video-player__progress 不能复用 .range 类
进度条是播放器上下文强依赖的元素，不是通用表单控件。复用 .range 会带来三重风险：
-
.range的 CSS 规则（如appearance: none、height、background）可能被全局 form 样式覆盖，导致进度条渲染异常 - Plyr 或自研播放器 JS 通过
.video-player__progress定位并绑定input事件，类名不匹配则拖动无效 - 进度条内部子元素（如缓冲区
.video-player__progress-bar、滑块.video-player__progress-thumb）必须与父块同域，否则无法精准控制伪元素::-webkit-slider-runnable-track
plyr__control 类名不可替换，且 data-plyr 属性必须存在
Plyr 的交互逻辑完全基于 class 名和 data-plyr 属性双重识别，手写自定义类等于切断 JS 绑定链：
- 播放按钮必须是
<button class="plyr__control" data-plyr="play">，仅加class="my-play-btn"不触发任何行为 - 音量滑块必须是
<input type="range" class="plyr__control" data-plyr="volume">，否则静音/调节值不会同步到player.volume - 所有状态类（如
.plyr--playing、.plyr--muted）均由 Plyr JS 动态添加到根容器，手动写.is-playing会导致图标与实际状态脱节
全屏按钮的激活态必须用 data-fullscreen 驱动，而非 --active 类
全屏是 document 级状态，CSS 类无法可靠反映 document.fullscreenElement 的真实值，硬靠类名切换会出竞态问题：
立即学习“前端免费学习笔记（深入）”；
- 点击按钮后 JS 调用
element.requestFullscreen()，但浏览器异步响应；此时若立即加.video-player__fullscreen-btn--active，可能早于fullscreenchange事件，造成 UI 滞后或误判 - 正确做法：JS 监听
fullscreenchange，动态在根容器写data-fullscreen="true"，再用属性选择器驱动样式：body:is([data-fullscreen="true"]) .video-player__fullscreen-btn - 禁用态（如 iOS Safari 不支持）也应由
data-fullscreen="disabled"控制，而不是靠.video-player__fullscreen-btn--disabled手动维护
音量控件必须拆成两个独立 Block：video-player__volume-toggle 和 video-player__volume-slider
按钮和滑块交互逻辑、DOM 结构、状态粒度完全不同，强行塞进一个 Block 会导致耦合和失控：
-
video-player__volume-toggle只负责切换静音，状态修饰符为--muted，JS 只需操作这个类名 -
video-player__volume-slider负责数值调节，显隐由--hidden控制，且其input事件应只影响player.volume，不触发静音逻辑 - 若共用
video-player__volume，就会出现video-player__volume--muted该加在哪个元素上、滑块是否该随静音自动隐藏等模糊边界问题
BEM 在音视频界面中最容易被忽略的点，是把“视觉相似”当成“语义相同”——进度条像 slider、按钮像 btn、遮罩像 modal，但只要脱离上下文，就不再是它自己。命名不是为了好看，是为了让每个 class 都能回答一个问题：“它属于谁？它代表什么状态？它能不能被单独替换而不影响别人？”
