step属性生效需同时满足：type为number/range/time等、显式设置min、value与min和step数学对齐；否则将静默修正导致交互异常。
step属性不生效，先查type和min是否匹配
step只对type="number"、type="range"、type="time"等少数类型起作用，type="text"加step完全无效。更隐蔽的问题是：没设min时，浏览器默认以0为起点算合法值，但你的业务起点可能不是0——比如折扣输入从0.01开始，却只写step="0.01"，结果0.01本身就不在0 + n × 0.01序列里（n=1时才是0.01），看似合理实则初始值就非法。
- 检查DOM：
input.type必须是"number"或"range"，不是"text"或"tel" - 确认
min已显式设置，且value满足value === min + n × parseFloat(step)（n为整数） -
type="time"的step单位是秒，写step="30"是30秒，不是30分钟；要15分钟得写step="900"
value初始值不对齐会导致静默修正和交互卡顿
浏览器不会报错，但会悄悄把value拉到最近合法值上——比如min="0"、step="0.25"、value="1.1"，Chrome可能直接改成1.0或1.25，导致第一次点↑按钮跳到1.25而不是1.35，用户感知就是“点不动”或“跳变”。这种静默修正无法通过console.log(input.value)发现，因为DOM属性已更新，但UI状态已错乱。
- 初始化时用
Math.round((value - min) / step) * step + min手动对齐，再赋值 - 避免写
value="1.05"配step="0.1"——1.05 ÷ 0.1 = 10.5，不是整数，必然被修正 - 服务端返回的初始值也要做同样校验，不能假设“前端会自动修”
浮点误差让step="0.1"在部分浏览器里变成step="1"
IEEE 754下0.1无法精确表示，旧版Chrome曾直接把step="0.1"解析成1，Safari对0.1的二进制处理也不稳定。用户输0.99提交失败，错误提示却是“最近合法值是0和1”，说明step根本没按0.01生效。
- 金额类输入一律换算单位：
min="100"、step="1"、value="199"表示1.99元 - 必须用小数时，统一写三位：
min="0.000"、max="10.000"、step="0.001"，比"0.1"更可靠 - 不要依赖
step="any"绕过问题——它在Safari 15.4前不支持，且会让required验证失效
动态改step后拖不动，是因为value没重置
执行input.step = "0.25"或input.setAttribute('step', '0.25')只是改了属性，浏览器不会自动重算当前value是否还在新步长序列里。原来value="1.1"在step="0.1"下合法，换成step="0.25"后，1.1不在0 + n×0.25里，拖动/方向键就会静默拉回1.0或1.25，造成卡顿。
立即学习“前端免费学习笔记（深入）”；
- 必须紧跟着重置
value：input.value = (Math.round(parseFloat(input.value) / 0.25) * 0.25).toFixed(2) - 优先用
setAttribute而非直接赋值step，部分Android WebView对后者无响应 - 连续切换step时，包一层
requestAnimationFrame，避免状态残留
真实项目里最常被忽略的是：value初始值、min、step三者必须数学对齐，缺一不可。浏览器不校验你写的value是否合法，但它会在你第一次交互时悄悄修正——而这个修正过程没有日志、不抛异常、不触发事件，只能靠手动校验逻辑兜底。
