controls属性无法个性化样式，必须移除后用HTML+CSS+JS重做整套控制逻辑；浏览器原生控件为黑盒，CSS无法穿透，伪类兼容性差且不稳定；移除后需JS手动接管播放、进度、音量、全屏等全部行为，并注意移动端autoplay、playsinline及手势触发等硬限制。
controls 属性不能“个性化样式”，只能开关浏览器原生控件；真要换皮肤、改布局、加动画，必须移除 controls，自己用 HTML + CSS + JS 重做整套控制逻辑。
为什么直接给 controls 加 CSS 没用
浏览器对 渲染的控件是黑盒：内部 DOM 结构不暴露，CSS 无法穿透选择进度条滑块或音量按钮。虽然部分 Chromium 内核支持 ::-webkit-media-controls 等伪类，但 Safari 和 Firefox 基本不认，且这些伪类随时可能被废弃。
常见误操作包括：
- 写
video::-webkit-media-controls-timeline { width: 100% }—— 在 Firefox 里完全无效 - 试图用
!important覆盖默认颜色 —— 只在 Chrome 里偶现生效，iOS Safari 下彻底失效 - 以为加了
controlslist="nodownload"就能隐藏下载按钮 —— 它只影响按钮是否显示，不影响样式
移除 controls 后，JS 必须手动接管所有行为
去掉 controls 属性后， 变成“哑巴”——点击没反应、拖拽无反馈、键盘空格键也不起作用。你得用 JS 显式调用 API 并监听事件：
-
video.play()和video.pause()必须由用户手势（click/tap）触发，否则移动端抛NotAllowedError - 进度条同步要双向绑定：
range.value = video.currentTime / video.duration，且需在timeupdate事件里更新，不能只靠一次赋值 - 音量控制不能只设
video.volume = 0.7，还要监听volumechange事件来响应用户拖动后的实际值 - 全屏切换要用
video.requestFullscreen()，并监听fullscreenchange来更新按钮图标状态
移动端特别要注意的三个硬限制
iOS 和 Android 对媒体控制有强制策略，绕不过去：
-
autoplay必须搭配muted才可能成功，单独写autoplay会被静默忽略 - 非静音视频的
play()调用，必须发生在用户 click/touchend 等可信任事件回调内；放在setTimeout或canplay回调里大概率失败 -
playsinline属性必须显式添加，否则 iOS Safari 默认强制全屏播放，哪怕你只是想嵌在一个卡片里
自定义进度条拖拽的节流与同步陷阱
用 做进度条很常见，但直接绑 input 事件会出问题：
- 拖拽过程中频繁触发
video.currentTime = ...，导致卡顿甚至 seek 失败 - 移动端 touchmove 的坐标计算容易出错：别用
event.offsetX（Safari 不支持），要用event.touches[0].clientX - progressBar.getBoundingClientRect().left - 跳转完成后，进度条
value不会自动更新，必须手动同步，且要在seeked事件里做，不是timeupdate
真正稳定的方案是：拖拽时只记录目标时间，在 change（松手）事件里执行一次 currentTime 设置，并在 seeked 后立刻同步 range.value。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
