step="0.01" 失效主因是 IEEE 754 浮点无法精确表示 0.01，旧版 Chrome 可能四舍五入为 step="1"，且初始 value 必须满足 value === min + n × step，否则浏览器静默修正；推荐统一小数位数（如 min="0.00"、step="0.01"）或换算整数单位（如“分”）。
step 属性本身就能支持微小数值调整，但直接写 step="0.01" 或更小值并不总能如预期工作——问题不在语法，而在浮点精度、浏览器解析逻辑和初始值对齐。
为什么 step="0.01" 在某些浏览器里“点了没反应”
这不是你写错了，而是 0.01 在 IEEE 754 浮点表示中无法精确存储，Chrome 旧版本甚至会把它四舍五入成 step="1"，导致方向键或箭头按钮每次跳 1 而不是 0.01。Safari 和 Firefox 对小数步长的容忍度也不同，尤其当 min 是整数（如 min="0"）而 step="0.01" 时，(value − min) % step 的浮点余数可能不为 0，触发 validity.stepMismatch。
解决办法不是换库，而是统一量级：
-
min、max、step全部用相同小数位数声明，比如min="0.00"、max="10.00"、step="0.01" - 避免混用
min="0"和step="0.01"—— 浏览器可能把 0 当作整数处理，后续计算失准 - 测试时用键盘方向键 + Shift（部分浏览器支持 10× 步进），比拖动滑块更能暴露步长是否真实生效
stepUp() 和 stepDown() 怎么确保微调不偏移
手动改 input.value = parseFloat(input.value) + 0.01 是危险操作：它绕过 min/max 校验、不触发 input 事件、还可能引入浮点误差（如 0.1 + 0.2 === 0.30000000000000004）。stepUp() 才是浏览器原生保障精度的接口。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
但它有个隐藏前提：当前 value 必须本身合法。如果初始值是 "1.005" 而 step="0.01"，stepUp() 可能静默失败或跳到意外位置。
- 调用前先检查：
if (!input.checkValidity()) { input.reportValidity(); return; } - 若需自定义步长（比如按钮点一次 ±0.05），临时改
input.step = "0.05"，再stepUp()，完事立刻恢复原step - 对小数运算结果做截断：
parseFloat((newVal).toFixed(10))，再赋值并触发input事件
金额类输入别碰小数 step，直接换算单位
想让用户输“19.99 元”，不要设 min="0" step="0.01" value="19.99"。浮点误差会让 19.99 在内存中变成 19.990000000000002，提交时被拦住，报错 “The two nearest valid values are 19.98 and 20.00”。
正确做法是退回到整数域：
-
min="0"、max="10000"、step="1"、value="1999"（单位：分） - 显示层用 JS 格式化：
(input.value / 100).toFixed(2)→"19.99" - 提交前再转回整数，彻底避开所有浮点陷阱
最易被忽略的一点：哪怕你把 step 设得再小，如果 value 初始值不满足 min + n × step，浏览器会在第一次交互（失焦、拖动、点箭头）时静默修正它——你看到的“卡住”“跳变”“点不动”，八成是这个隐式重置在起作用，而不是 step 本身失效。
