需禁用原生控件，用自定义<input type="range">+JS同步时间：设appearance: none，用浏览器前缀伪元素定制样式，监听input事件实时拖拽、timeupdate事件更新进度，注意loadedmetadata后初始化max及跨端兼容性。
怎么用 CSS 重写 <input type="range"> 的样式
html 视频进度条本质是浏览器内置的 <input type="range"> 控件，它被包裹在 <video> 的 shadow dom 里，不能直接选中。想自定义，必须通过伪元素 + 全局 css 变量或覆盖默认样式来实现。
主流浏览器（Chrome/Firefox/Safari）对 input[type="range"] 的伪元素支持不一致，Safari 对 ::-webkit-slider-thumb 支持稳定，但 ::-moz-range-thumb 和 ::-ms-thumb 已逐步废弃；Firefox 现在主要靠 ::thumb（标准伪类）和 ::track。
- 必须给
input设置appearance: none，否则所有自定义样式会被忽略 - Chrome/Edge 需同时写
::-webkit-slider-thumb和::-webkit-slider-runnable-track - Firefox 要用
::thumb+::track，且需配合appearance: auto回退（否则可能失效） - Safari 16.4+ 开始支持
::thumb，但旧版仍依赖::-webkit-前缀
video::-webkit-media-controls-timeline {
display: none;
}
video::part(timeline) {
display: none;
}
/* 手动插入一个外部 range 控件并绑定 timeupdate */
<input type="range" id="custom-timeline" min="0" max="100">
为什么直接改 video::-webkit-media-controls-timeline 失败了
这个伪元素在 Chrome 95+、Edge 95+ 中已被移除，现在用的是 video::part(timeline) —— 但它属于 Shadow Parts API，需要先在 video 标签上加 exportparts="timeline" 才能穿透样式，而原生控件默认不导出。
更现实的问题是：即使你写了 video::part(timeline)，也无法单独控制滑块大小、轨道颜色或拖拽反馈，因为 timeline 是个复合组件，内部没有细分 part 名称。
- Chrome 95+ 后
::-webkit-media-controls-timeline完全无效，CSS 不会匹配 -
video::-webkit-media-controls-panel可隐藏整个控制栏，但无法只定制进度条 - 试图用 JavaScript 操作
shadowRoot读取原生 timeline 元素会失败：Chrome 禁止访问 media 控件的 shadow DOM - 唯一可靠路径是禁用原生控件（
controlslist="nodownload noremoteplayback"+controls移除），自己实现 UI
用 JS + 自定义 <input type="range"> 同步视频时间的坑
手动替换进度条后，核心是让 input 的 value 和 video.currentTime 实时同步，但容易卡顿、跳帧或失去精度。
立即学习“前端免费学习笔记（深入）”；
关键不是“绑 timeupdate”，而是要区分拖拽中（seeking）和播放中（playing）两种状态，否则用户拖动时会触发多余更新，造成抖动。
- 监听
input的input事件（非change）捕获实时拖拽值，立刻设video.currentTime = value * duration - 监听
video的timeupdate事件时，先检查video.seeking === false再更新input.value，避免拖拽中途被覆盖 - 务必在
loadedmetadata后才初始化max属性：input.max = video.duration || 0，否则初始为 0，拖动无效 - 移动端需额外处理
touchstart/touchend，因为input的input事件在 iOS Safari 上延迟明显
兼容性与性能要注意的硬限制
自定义进度条不是纯样式问题，它牵扯到事件流、时间精度、设备输入差异，稍不注意就会在某个平台完全失灵。
比如 iOS Safari 的 video.currentTime 设定后不会立即生效，而是触发 seeking → seeked，如果你在 seeked 里又去更新 input，就可能形成循环；Android Chrome 则对 requestVideoFrameCallback 支持更好，但普通项目没必要上。
- 不要用
setInterval定时更新进度条，timeupdate本身已足够（约 200–250ms 触发一次） -
video.duration在未加载元数据前是NaN，直接赋给input.max会导致input.value计算错误 - 如果视频启用了 DRM（如 Widevine），部分浏览器会禁止自定义控件或拦截
currentTime设置 - 用
transform: scaleX()动画拖拽滑块比直接改left更流畅，但需确保父容器overflow: hidden不裁切
真正难的不是写几行 CSS 或 JS，而是把播放状态机、事件优先级、跨端输入响应这三者对齐。多数人卡在“看起来动了”，其实拖拽松手瞬间有 100–300ms 的时间差没处理——这个点，调试时得打开 performance 面板看帧率，而不是只盯 console。
