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就僵住了
