正确做法是将金额转为整数单位（如元→分），用 min="0"、step="1"、value="199" 表示 1.99 元，显示层格式化，后端按“分”处理，彻底规避浮点精度问题。
step="0.01" 不能直接写，必须对齐 min 和 value
设 step="0.01" 却发现输入 1.25 后点提交报错“Please enter a valid value”，大概率是 min 或 value 没对齐步长基准。浏览器校验逻辑是：当前值必须满足 value === min + n × step（n 为整数）。若 min="0"、step="0.01"，但 value="1.25"，1.25 ÷ 0.01 = 125，看似合法——但浮点表示下 0.01 实际是近似值，部分浏览器会静默修正 value 到最近可表示的合法值（如 1.2499999999999998），导致校验失败。
正确做法：
-
min显式写满小数位：min="0.00"，而非min="0" -
value必须是精确倍数且字符串形式对齐：value="1.25"（不是1.25数字字面量，JS 赋值时要用.toFixed(2)） - 配合
max="999.99"等显式边界，避免浏览器推导出错
step="any" 不是“放开所有限制”，而是退化为 ±1 增减
想保留原生 spinner 按钮，又允许用户手动输任意小数（如 3.1415926），很多人直接上 step="any"。但它的真实行为是：禁用 validity.stepMismatch 校验，但上下箭头和 stepUp() 仍按整数 ±1 执行——value="1.5" 时点 ↑，结果是 2.5，不是 1.6。
这容易造成 UI 和逻辑预期错位。更麻烦的是：step="any" 在旧版 iOS Safari 或 Android WebView 中可能被忽略，降级为 step="1"，且不报任何警告。
立即学习“前端免费学习笔记（深入）”；
安全替代方案：
- 用
type="text"+inputmode="decimal"+ 正则监听（如/^-?\d*\.?\d{0,10}$/） - 若坚持用
type="number"，至少补上min和max，否则 Chrome 控制台会 warn 并启用默认step="1" - 提交前别依赖
checkValidity()判定精度，改用 JS 自校验字符串格式
动态改 step 后 spinner 失灵？重置 value 是硬性要求
运行时调用 input.setAttribute('step', '0.25') 后，发现拖滑块卡住、点 ↑ 跳到奇怪数字，根本原因是：浏览器不会自动重算当前 value 是否仍在新步长的合法集合内。旧 value="1.3" 在 step="0.25" 下非法（1.3 ÷ 0.25 = 5.2），松手或点击时会被强制拉回 1.25 或 1.5。
必须同步规整 value：
- 先
input.setAttribute('step', '0.25') - 再
input.value = (Math.round(parseFloat(input.value) / 0.25) * 0.25).toFixed(2) - 快速连续切换时，用
requestAnimationFrame包一层，避免状态残留 - 最后调用
input.checkValidity()，必要时input.reportValidity()
金额类输入永远别碰浮点 step
step="0.1" 在 Chrome 旧版本中曾被静默四舍五入成 step="1"；step="0.01" 在二进制浮点下本质仍是近似值，0.01 * 100 可能得 0.9999999999999999。这不是 bug，是 IEEE 754 的宿命。
生产环境唯一靠谱方案：
- 全部换算为整数单位：元 → 分，
min="0"、step="1"、value="199"表示 1.99 元 - 显示层用
(value / 100).toFixed(2)格式化，不参与计算 - 后端接收时也按“分”处理，彻底绕过浮点链路
真正难的从来不是写对 step，而是用户粘贴 "1.23abc"、用语音输入、或在移动端键盘切来切去——这些行为完全绕过所有原生约束，step 形同虚设。
