step属性控制滑动条合法停靠位置而非渲染精度，value初始值必须满足value === min + n × step，否则浏览器静默修正导致卡顿、跳变；小数步长应统一小数位数或改用整数单位。
step属性控制滑动条的“跳变点”，不是渲染精度
滑动条（type="range"）的 step 属性只约束用户拖动或按方向键时的**合法停靠位置**，不影响视觉渲染——哪怕设成 step="0.001"，实际拖动仍受限于屏幕像素密度和浏览器实现，用户根本感知不到千分之一的变化。
常见错误现象：滑块拖到某处突然“卡住”、松手后自动跳回、方向键微调不按预期步进。
- 根本原因往往是
value初始值不满足value === min + n × step（n为整数），浏览器静默修正导致状态错位 -
min="0" step="0.1" value="1.05"是非法组合，Chrome 会悄悄把value改成1.0或1.1，但 DOM 上看不到变化 - 移动端 iOS Safari 对小步长（
step ）支持不稳定，部分版本直接降级为 <code>step="1"
动态改step后滑块失灵？必须重置value并用setAttribute
直接赋值 el.step = "0.25" 不可靠，浏览器不会自动重算合法值集合，旧 value 可能已越界，导致拖不动或跳变异常。
- 正确做法：先用
el.setAttribute("step", "0.25")更新属性，再手动重置value - 重置逻辑推荐：
el.value = (Math.round(parseFloat(el.value) / 0.25) * 0.25).toFixed(2) - 快速连续切换
step时，加一层requestAnimationFrame延迟执行重置，避免状态残留 - 改完建议立即调用
el.checkValidity()主动触发校验，配合el.reportValidity()显示提示（如有需要）
小数步长踩坑最多：浮点误差+浏览器四舍五入
step="0.1" 在二进制中无法精确表示，某些旧版 Chrome 甚至会把它四舍五入成 step="1"；用户输入 2.05 也会被原生验证拦截，报错“值必须为 0.1 的倍数”。
- 最稳妥方案：用整数单位。金额用“分”，设
min="100" step="1"，显示时再除以 100 - 必须用小数时，
min、max、step全部统一小数位数，例如全写成min="0.00" max="10.00" step="0.01" - 避免 JS 手动计算增减：
parseFloat(val) + 0.25容易产生0.30000000000000004这类误差 - 优先用原生方法：
inputEl.stepUp(1)和inputEl.stepDown(1)，它们严格按step属性执行，不走 JS 浮点运算
想支持键盘微调 0.01？min/max 范围不能太大
浏览器对 step 的解析依赖于 min 和 max 的数值量级。如果 min="0" max="100" 却设 step="0.01"，旧版 Chrome 可能直接四舍五入成 step="1"。
- 实测有效策略：把范围缩到 10 以内，比如
min="0.00" max="10.00" step="0.01" - 方向键测试必须做：单独按 ←/→ 应每次跳
step，按 Shift+←/→ 应跳10×step（部分浏览器支持） -
step="any"不是解药：Safari 15.4 之前不支持，Firefox 某些版本忽略它，且会让required验证失效 - 真正需要高精度微调（如音频时间轴），建议换用
type="number"+ 按钮组合，体验比强压range更可控
浏览器对 step 的静默处理和浮点兼容性差异，是多数人调试半天才发现不了的盲区。别只盯着属性写了没，重点检查 value 是否从初始化就合规，以及 min/max/step 三者的小数位数是否一致。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
