step属性仅约束浏览器内置增减和提交校验，不拦截手动输入；初始value必须与min、step对齐，否则浏览器会静默修正；金额场景建议换算单位避免浮点误差。
step 属性不会阻止用户手动输入非法值，它只约束浏览器内置增减行为和表单提交校验。 你看到的“值必须为 0.1 的倍数”报错，是提交时触发的原生验证，不是实时拦截；而用户粘贴、拖动滑块、用方向键微调时，step 才真正起作用——前提是 value 初始值、min、step 三者对齐。
type="number" 的 step 必须配合 min 和 value 初始化才生效
浏览器不会校验你写的 value 是否合法，但会静默修正它：如果 value 不满足 value === min + n × step（n 为整数），Chrome 和 Safari 可能直接把 value 改成最近合法值，导致 spinner 点不动、拖拽卡顿、第一次点击 ↑ 就跳到意外数字。
- 错误写法：
<input type="number" min="0" step="0.1" value="1.05">→ 浏览器可能悄悄改成1.0或1.1，DOM 上看不出变化 - 正确写法：
<input type="number" min="0" step="0.1" value="1.0">或value="1.1"，确保初始值本身就是步长整数倍 - 金额类场景强烈建议换算单位：
min="100"、step="1"、value="199"表示 1.99 元，彻底避开浮点精度问题
step="0.1" 在 Chrome/Safari 中失效的真正原因
这不是 bug，而是 IEEE 754 浮点表示缺陷：0.1 在二进制中无法精确存储，部分旧版 Chrome 甚至会把 step="0.1" 四舍五入成 step="1"，导致所有增减都按整数跳。用户输入 2.05 后点提交，就会触发 validity.stepMismatch。
- 临时缓解：写成
step="0.10"或step="0.100"，某些浏览器对末尾零更敏感 - 可靠方案：统一小数位数，
min="0.00"、max="10.00"、step="0.01"，避免混用整数与小数 - 别信“设了就管用”——移动端 iOS Safari 的 number 键盘甚至不保证显示小数点，
step="0.1"可能让用户根本输不了小数
动态修改 step 后 spinner 失灵？重置 value 是必须步骤
直接改 input.step = "0.25" 不可靠，浏览器不会自动重算合法值集合。旧 value 很可能已越界，导致拖不动、松手跳变、方向键失灵。
- 正确做法：先
input.setAttribute("step", "0.25")，再手动规整 value：input.value = (Math.round(parseFloat(input.value) / 0.25) * 0.25).toFixed(2) - 快速连续切换 step 时，加
requestAnimationFrame延迟重置，避免状态残留 - 改完立即调用
input.checkValidity()，必要时input.reportValidity()主动提示 - 实现 ± 按钮时，别用
parseFloat(val) + 0.25——优先调用input.stepUp(1)和input.stepDown(1)，它们严格按当前 step 执行，不走 JS 浮点运算
type="range" 的 step 控制的是“跳变点”，不是渲染精度
哪怕设 step="0.001"，滑块拖动仍受限于像素密度和浏览器实现。用户根本感知不到千分之一的变化，反而容易因 value 初始不合规导致卡顿或自动跳回。
- 滑块的最小可感变化远大于数学精度，别压低 step 试图提升“精度”
- 若需精细控制（如音频时间轴），建议改用
type="number"+ 自定义按钮组合，体验更可控 - 测试时直接用键盘方向键 +
Shift（部分浏览器支持 10× 步进），确认是否真按预期跳变，比盯着 UI 更准
真正麻烦的从来不是写 step，而是用户粘贴、拖拽滚动条、第三方输入法带来的各种绕过路径——这些地方 step 属性根本不起作用。
