唯一彻底避开浮点误差的方案是用整数单位替代小数步长，如“元”转“分”、“摄氏度”转“十分之一度”，使所有值为整数，step回归稳定。
直接用整数单位替代小数步长，是唯一能彻底避开浮点误差的方案。别在 step 上硬刚 0.1、0.05 这类值——它们在二进制里本就无法精确表示，浏览器每次累加都在放大误差。
为什么 step="0.1" 点两次 ↑ 就变成 0.30000000000000004
这不是 bug，是 IEEE 754 双精度浮点数的固有表现。0.1 存储为近似值，多次 stepUp() 或手动计算 parseFloat(val) + 0.1 都会累积偏差。浏览器内部校验时比对的是“原始输入字符串”和“由浮点累加生成的合法序列”，二者天然不匹配。
-
step="0.1"在旧版 Chrome 中可能被静默降级为step="1" - 用户输入
"0.3"后失焦，Chrome 可能自动跳回"0.2"或"0.4"，因为0.3不在它算出的合法序列里 -
min="1"step="0.3"的合法起点不是1.0，而是离1最近的min + n × step值（如1.2），不同浏览器实现可能不一致
金额、温度等业务场景必须用整数单位
把“元”换成“分”、“摄氏度”换成“十分之一度”，让所有值变成整数，step 自然回归稳定。
- 价格输入框：
min="0"→min="0"（单位：分），step="1"，value="199"表示 1.99 元 - 温度调节：
min="-2731"（-273.1℃），max="1000"（100.0℃），step="1"，显示层用(value / 10).toFixed(1)格式化 - 后端接收后也按整数处理，避免任何
value % 0.01类浮点模运算
非金额场景若必须用小数，得靠初始化对齐 + stepUp/stepDown
step 的数学约束是 value === min + n × step（n 为整数）。只要初始 value 不满足，浏览器就会静默修正，导致 spinner 卡死、拖拽跳变。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 设
min="0.00"max="10.00"step="0.01"，则value必须显式写成"0.00"、"5.99"、"10.00"等两位小数字符串 - 动态改
step后，必须重置value：input.value = (Math.round(parseFloat(input.value) / 0.25) * 0.25).toFixed(2) - 增减操作优先调用
input.stepUp(1)和input.stepDown(1)，它们严格按当前step执行，不走 JS 浮点运算 - 别信
step="0.100"或step="0.10"能缓解问题——这只是部分浏览器对末尾零更敏感，不可靠
step="any" 不是解药，只是关掉校验开关
step="any" 只禁用步长校验，不改变 valueAsNumber 的 IEEE 754 解析行为。输入 "0.1" 后读 input.valueAsNumber，仍是 0.10000000000000001；"0.1" + "0.2" 运算结果还是 0.30000000000000004。
- 上下箭头退化为 ±1 整数增减，
value="1.5"点 ↑ 变成"2.5"，不是你想要的"1.6" - iOS Safari ≤15.4 完全忽略
step="any"，仍按step="1"校验，小数输入直接触发validity.badInput - 真正需要高精度时，应换
type="text"+inputmode="decimal"+ 字符串校验，或引入decimal.js等库做运算
最麻烦的从来不是怎么写 step，而是用户粘贴、拖动滑块、用第三方输入法——这些行为完全绕过所有原生约束。前端能做的只有对齐初始值、用整数单位、禁用浮点运算路径；后端必须独立校验范围与小数位数，不能信任任何来自 step 的“合法性”。
