根本原因是浮点精度误差导致浏览器验证时 value ≠ min + n × step，触发 stepMismatch；解决方法是改用整数单位、step="any" 或完全自控校验。
step 属性设为小数（比如 step="0.1"）后表单无法提交，根本原因不是写法错，而是浏览器在验证时发现输入值不满足 min + n × step 这一数学约束——尤其当浮点精度误差让计算结果“差一点点”，就会触发 validity.stepMismatch === true。
为什么 step="0.1" 输入 "0.3" 却被拒绝
- 浏览器内部用二进制表示十进制小数，
0.1无法精确存储，实际是0.10000000000000000555... - 累加三次后，
0.1 + 0.1 + 0.1≈0.30000000000000004，不等于你输入的字符串"0.3" - 表单提交时，浏览器检查是否满足
value === min + n × step（严格相等），失败 →stepMismatch
常见现象：
- 用户手动输入
"0.3"，点提交，输入框标红，控制台打印input.validity.stepMismatch为true - 滑块拖到“看起来是 0.3”的位置，
input.value返回"0.30000000000000004" - 初始
value="0.15"配step="0.1"，Chrome 可能静默把 value 改成"0.1"或"0.2"，导致 spinner 卡死
解决思路不是“修浮点”，而是绕开它：
- 改用整数单位：比如利率、金额、折扣，统一用“分”“厘”“百分点”等整数表达
-
min="0",max="1000",step="1"，再用 JS 显示为value / 100 - 或直接用
step="any"，放弃原生步长校验，改由 JS 全权控制输入与格式化
step="0.01" 在金额/利率场景为何仍可能失败
step="0.01" 看似合理，但实际陷阱密集：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
-
min和max必须与step兼容：比如min="3"+step="0.01"→ 合法值从 3.00 开始，但3.005仍非法；而min="3.00"才明确起点是两位小数 - Safari 移动端数字键盘常不显示小数点，用户根本输不了
"4.35"，只能粘贴或切键盘——此时step形同虚设 - 用户粘贴
"4.355"或输入"4,35"（逗号分隔），step完全不拦截，只等提交时报错
真正可用的组合：
-
<input type="number" min="0" max="10000" step="1" inputmode="decimal">（金额存“分”） - 失焦时 JS 处理：
parseFloat(value) * 100→ 取整 → 存整数；显示时除以 100 并.toFixed(2) - 提交前校验：
if (value % 1 !== 0 || value < 0 || value > 10000)，比依赖stepMismatch可靠得多
为什么 setCustomValidity() 改不了默认提示文案
调用 input.setCustomValidity("请输入两位小数") 后，reportValidity() 仍可能弹出浏览器原生提示（如 Chrome 的“值必须为 0.01 的整数倍”），因为：
-
stepMismatch触发时，validationMessage是只读推导值，不能直接覆盖 - 必须在监听事件中先判断 validity.stepMismatch 是否为 true，再设自定义文案；且一旦校验通过，必须立刻
setCustomValidity("")，否则后续reportValidity()会持续返回旧文案 - 更稳妥的做法是：干脆不用原生
step校验，把type改成"text"，用inputmode="decimal"+ 正则 +parseFloat+ 范围检查，全程自己掌控
最常被忽略的一点：所有这些 step 行为，只在用户主动触发表单验证（submit / checkValidity() / reportValidity()）时才发生。它不拦截粘贴、不阻止键盘输入、不修正光标位置——想“实时限制”，JS 是唯一出路。
