step属性控制提交校验和上下箭头增量，不阻止任意输入；其校验逻辑为(value - min) % step === 0，受浮点精度影响易失效，推荐用整数单位或初始化值严格匹配步进。
number 输入框的 step 属性到底控制什么
它只约束用户手动输入后「提交时校验」和「点击上下箭头时的增量变化」，不阻止用户直接输入任意数字。比如 step="0.1" 时，输入 1.23 不会立刻报错，但点一次向上箭头会跳到 1.3，而不是 1.23 + 0.1 = 1.33——因为浏览器内部按「当前值 + step」再取最接近的合法步进值计算。
为什么设置了 step="0.1" 却无法输入小数点后两位
常见现象：用户在 <input type="number" step="0.1"> 中尝试输入 2.45，输完自动变成 2.4 或触发 Invalid input 提示。这不是 bug，而是浏览器对 step 的严格解析逻辑：它要求最终值必须满足 (value - min) % step === 0（若未设 min，则按 value % step === 0 校验）。而浮点数精度问题会让 2.45 % 0.1 计算结果不为 0。
- 解决办法是改用整数倍表达：把单位换算成「分」「毫秒」「像素」等，例如金额用「分」代替「元」，
step="1"+value="245"表示 2.45 元 - 或显式设置
min和step组合，如min="0" step="0.01"，但需注意部分旧版 Safari 对step="0.01"支持不稳定 - 避免依赖
step做格式限制，它不是输入掩码（mask）
如何让上下箭头真正按预期步进（比如每次 ±0.01）
关键在于初始化值必须是 step 的整数倍，否则第一次点击箭头就会“跳偏”。例如：<input type="number" value="1" step="0.01">，初始值 1 是 0.01 的 100 倍，没问题；但若写成 value="1.0"，某些浏览器会因字符串解析差异导致内部值为 1.0000000000000002，后续加减就失准。
- 始终用整数或明确可被
step整除的小数初始化：value="1.00"或更稳妥地用value="100"配合单位换算 - 监听
input事件做实时修正：检查parseFloat(e.target.value) % step !== 0时，用Math.round(value / step) * step四舍五入对齐 - 禁用原生箭头（
appearance: none）+ 自研按钮更可控，尤其需要支持大范围增减或非线性步进时
移动端 number 输入框的 step 行为差异
iOS Safari 的软键盘 number 模式不显示小数点按钮（除非设 step="any" 或含小数的 min/max），且点击箭头可能忽略 step 直接按 1 增减。Android 各厂商 WebView 表现也不统一。
- 强制触发小数键盘：加
inputmode="decimal"（比type="number"更可靠） - 放弃依赖原生箭头，在移动端默认隐藏它们（
::-webkit-inner-spin-button { display: none; }），只保留输入框+自定义 +/- 按钮 -
step="any"可绕过校验，但失去步进约束，适合仅需数字键盘的场景
浏览器对 step 的实现细节藏得深，尤其在浮点运算、初始值解析和移动端软键盘联动上，很容易以为设了就生效。实际要用，得先想清楚：你到底要的是「用户操作引导」，还是「数据合法性兜底」——前者靠 UI 辅助，后者必须服务端校验。
