CSS 没有：buffering 伪类，必须用 waiting/canplay 事件配合 class 或 data-buffering 属性控制 UI；buffered 属性不可响应式驱动样式，仅适用于进度条等特定场景。
video 元素没有 buffering 伪类，别白费劲找:buffering
浏览器根本没实现 :buffering 这类 CSS 伪类——查 MDN、看 Can I Use、翻 W3C 草案都确认了：它不存在。所有想靠纯 CSS 监听视频缓冲状态的方案，到这一步就该停了。
用 waiting 和canplay事件配合 class 切换来模拟
真实可用的路径是监听原生事件，手动增删 class。视频进入缓冲（卡顿）时触发 waiting，恢复可播放时触发canplay 或canplaythrough。注意：canplay不代表完全加载完，只是“够播几帧了”；canplaythrough才更接近“大概率不会卡”，但仍有风险。
实操建议：
- 给
<video>加一个初始 class，比如is-loading，对应骨架屏或 loading 动画 - 监听
waiting事件，不覆盖 已有 class，只确保is-loading存在 - 监听
canplay后，用setTimeout延后 100ms 再移除is-loading——避免因解码延迟导致刚移除又立刻触发waiting - 如果页面有多个视频，别用
document.querySelector('video')硬写，改用event.currentTarget精准操作当前实例
buffered属性只能读，不能触发 CSS 重绘
video.buffered返回 TimeRanges 对象，反映已缓存的时间段，但它不是响应式数据——修改它不会触发 DOM 更新，也无法绑定到 CSS。有人试图轮询 buffered.end(0) 然后强制 offsetHeight 触发重排，既低效又不可靠。
立即学习 “ 前端免费学习笔记（深入）”；
真正有用的做法：
- 仅在需要精确控制 UI（如进度条 buffer 层）时读取
buffered，配合timeupdate事件做节流更新 - 不要把它当状态源去驱动整体加载态；
waiting/canplay才是信号主干 - 移动端 Safari 对
buffered支持不稳定，某些 HLS 流里可能始终为空，得备 fallback 逻辑
自定义 data-buffering 属性 +CSS 属性选择器是折中方案
如果你坚持用 CSS 驱动，唯一可行的“类伪类”方式是手动维护 data-buffering 属性值，并用属性选择器写样式。例如：video[data-buffering="true"] {opacity: 0.7;}。但这仍是 JS 驱动，不是 CSS 自动感知。
关键细节：
- 必须用
setAttribute而非dataset赋值，否则 IE11 不识别 - 避免频繁设为
"true"/"false"，改用"pending"/"ready"等语义值，方便未来扩展 - 记得在
error事件里清理状态，否则视频失败后还挂着data-buffering="pending"，UI 就僵住了
