原生 range 输入框需用 appearance: none 和浏览器专属伪元素才能自定义样式，仅写通用 CSS 无效；必须分别处理 WebKit、Mozilla 和实验性标准三套规则，且交互中需用 input 事件、数值转换和 JS 填充避免兼容性问题。
原生 input[type="range"] 不能靠常规 CSS 改样式，必须用浏览器特定伪元素 + appearance: none 才能真正接管外观。只写一套规则，在 Firefox 或 Safari 下大概率白忙活。
为什么直接写 width/height/background 没用
因为 Chrome、Firefox、Safari 各自把滑块渲染成系统控件，width、height、background 这类通用属性对轨道（track）和滑钮（thumb）完全不生效。你看到的“能调粗细”其实是浏览器默认渲染的副作用，不是可控样式。
必须显式禁用原生外观：
-
appearance: none是起点，但只对 WebKit/Blink 有效；Firefox 需要单独处理::-moz-range-thumb等伪类 - 没加
appearance: none就设width和height，Chrome 下 thumb 尺寸会被忽略 - Safari 对
::-webkit-slider-thumb支持不稳定，某些版本下border-radius失效或位置偏移
跨浏览器伪元素怎么写才不漏掉
三套规则缺一不可，顺序建议按浏览器使用率排：WebKit → Mozilla → 实验性标准。别指望 ::thumb 能覆盖全部。
立即学习“前端免费学习笔记（深入）”；
- Chrome/Edge/Safari（部分）：
::-webkit-slider-thumb+::-webkit-slider-runnable-track - Firefox：
::-moz-range-thumb+::-moz-range-track - 实验性通用写法（支持度低）：
::thumb/::track，目前仅 Safari 15.4+ 有限支持 - IE 完全不支持这些伪类，
input[type="range"]在 IE10–11 中只能用默认样式或 JS 模拟
监听滑动值时容易错在哪几个点
样式只是表层，交互逻辑出错会让整个控件“看起来正常但用不了”。最常踩的坑集中在事件和数据类型上。
- 用
change事件监听——结果拖动时不更新，松手才触发一次；正确做法是绑定input事件 -
input.value永远是字符串，不做Number(input.value)转换，后续做+运算会拼接（比如"20" + 1 === "201"） - 移动端 iOS Safari 的
input事件在快速拖动时可能丢帧，需加touch-action: none防止滚动冲突 - 没设
min/max时，value默认是"50"，不是"0"，也不是空值
进度条填充怎么做才准
想让轨道左侧随滑块位置变色（比如音量条），不能靠伪元素自身渐变——各浏览器对 background-position 解析不一致，thumb 居中时填充起点经常偏移。
更可靠的做法是用一个绝对定位的 <div> 做“假轨道”，通过 JS 动态更新其 <code>width：
<div class="range-wrapper"> <input type="range" id="vol" min="0" max="100" value="30"> <div class="range-fill"></div> </div>
然后监听 input 事件计算比例：
const input = document.getElementById('vol');
const fill = document.querySelector('.range-fill');
input.addEventListener('input', () => {
const percent = (input.value - input.min) / (input.max - input.min) * 100;
fill.style.width = `${percent}%`;
});
这样避免了伪元素渲染差异，也绕开了 Safari 对 linear-gradient 在 track 上的 bug。
真正难的不是写几行 CSS，而是记住每套伪类只在对应内核里起作用，且 thumb 的尺寸、定位、z-index 在不同浏览器里行为不统一。如果项目需要强一致性（比如设计系统组件），直接用 noUiSlider 或 slider 类库比硬刚原生更省时间。
