step属性只控制滑动条合法停靠位置，不控制渲染精度；value初始值必须满足value === min + n × step，否则浏览器静默修正导致卡顿、跳变。
step 属性不控制“渲染精度”，只定义合法停靠点；设了不一定生效，value 初始值必须满足 value === min + n × step，否则浏览器静默修正——这是 90% 的卡顿、跳变、拖不动问题的根源。
为什么滑块拖到一半突然卡住或自动跳回
滑块（type="range"）的 step 只决定“哪些数值是允许停靠的”，不是像素级拖动精度。用户拖动时，松手瞬间浏览器会把当前值强制对齐到最近的合法点：min + n × step。
- 若
min="0"、step="0.1"、value="1.05"，该值非法，Chrome 会悄悄改成1.0或1.1，但 DOM 中input.value看不出变化，导致后续拖动逻辑错乱 - 移动端 iOS Safari 对
step 支持极不稳定，部分版本直接降级为 <code>step="1" - 滑块 UI 本身不画刻度，所谓“精度”只是数学约束，和视觉反馈无关
为什么 step="0.1" 点两次 ↑ 变成 0.30000000000000004
这不是 bug，是浮点数在二进制中无法精确表示 0.1 导致的底层误差。现代浏览器虽做了部分修正，但旧版 Chrome 曾直接把 step="0.1" 四舍五入为 step="1"。
- 推荐用整数单位：金额用“分”，设
min="100"、step="1"、value="199"表示 1.99 元 - 必须用小数时，统一写法：
min="0.00"、max="10.00"、step="0.01"，避免min="0"和step="0.01"混用 - 别手动算：
parseFloat(val) + 0.1→ 改用原生input.stepUp(1)，它严格按当前step执行，不走 JS 浮点运算
动态改 step 后滑块/数字框失灵怎么办
直接赋值 el.step = "0.25" 不可靠——浏览器不会自动重算合法值集合，旧 value 很可能已越界。
- 用
el.setAttribute("step", "0.25")，部分浏览器响应更稳定 - 紧接着重置
value：el.value = (Math.round(parseFloat(el.value) / 0.25) * 0.25).toFixed(2) - 快速连续切换时，加
requestAnimationFrame延迟执行重置，避免状态残留 - 改完立刻调用
el.checkValidity()主动校验，必要时el.reportValidity()提示用户
step="any" 是不是就完全不限制了
不是。“any”只是禁用步长对齐逻辑，不代表放开一切约束：
- 上下箭头和
stepUp()会退化为 ±1 整数增减（哪怕当前值是1.5，点 ↑ 变成2.5，不是1.6） - 仍会校验是否为合法数字（不能输
abc），但不再触发validity.stepMismatch - 手动输入
1.23456789依然允许，表单提交前也不会报错——业务上需 JS 或后端兜底
真正麻烦的从来不是写 step，而是用户粘贴、拖拽滚动条、第三方输入法绕过所有原生约束——这些地方 step 根本不起作用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
