浮点误差导致step="0.1"累加异常，应使用input.stepUp()、以“分”为单位、确保value符合min+n×step约束、动态改step后重置value、step="any"仅禁用对齐但不放开精度限制。
step="0.1" 点两次 ↑ 变成 0.30000000000000004 怎么办
这不是 step 的 bug，是 IEEE 754 浮点数在二进制里根本存不准 0.1 导致的。浏览器用它算步进，累加就暴露误差。旧版 Chrome 甚至会直接把 step="0.1" 当作 step="1" 处理。
- 别手动写
parseFloat(val) + 0.1—— 改用原生input.stepUp(1)，它严格按当前step值执行，不走 JS 浮点运算 - 金额类场景一律用“分”：设
min="100"、step="1"、value="199"表示 1.99 元 - 必须用小数时，统一补零写法：
min="0.00"、max="10.00"、step="0.01"；避免min="0"和step="0.01"混用
value 初始值不匹配 step 就卡住
step 不是独立开关，它和 min、value 构成数学约束：value 必须满足 value === min + n × step（n 为整数）。否则浏览器静默修正——你拖不动滑块、点 ↑ 却跳到非预期值、spinner 按钮失灵，八成卡在这儿。
- 例如：
min="1"、step="0.3"，却设value="1.0"→ Chrome 可能悄悄改成"1.2"或让控件失效 - 安全写法：
min="0.0"、step="0.1"，则value必须是"0.0"、"0.1"、"0.2"… 之一 - 动态改
step后必须立刻重置value：input.value = (Math.round(parseFloat(input.value) / newStep) * newStep).toFixed(2)
step="any" 并不是“放开所有限制”
step="any" 只禁用步长对齐逻辑，不代表放弃校验或获得任意精度：
- 上下箭头和
stepUp()全部退化为 ±1 整数增减：当前value="1.5"，点 ↑ 变成"2.5"，不是"1.6" - 仍校验是否为合法数字（不能输
"abc"），但不再触发validity.stepMismatch -
valueAsNumber仍是 IEEE 754 双精度解析结果，"0.1"读出来还是0.10000000000000001 - Safari ≤15.4 完全忽略
step="any"；16.4+ 虽支持，但粘贴高精度数字可能被自动四舍五入
真正要限制小数位数，得靠 JS 配合 blur
step 只管提示和原生验证，不阻止手动输入多余位数。用户粘贴、拖拽滚动条、第三方输入法完全绕过它。
立即学习“前端免费学习笔记（深入）”；
- 监听
blur比input更合理——避免干扰正在输入的过程 - 用
parseFloat(input.value).toFixed(2)格式化，注意返回字符串；若需截断，改用Math.floor(parseFloat(input.value) * 100) / 100 - 设置
input.value后要同步更新视图，否则显示滞后 - 移动端软键盘可能忽略
step，直接弹出纯数字键盘，建议加inputmode="decimal"
实际麻烦从来不是写 step，而是用户行为不可控——粘贴、拖拽、输入法、键盘快捷键，这些都绕过它的约束。它只在提交校验和 UI 微调时悄悄发力，漏掉它，表单看似能用，一提交就卡在 stepMismatch；过度依赖它，又容易误以为前端已做了完整控制。
