step属性仅对type="number"和type="date"等特定类型生效，控制交互增减单位、约束合法值序列及表单验证，但受浮点精度影响易校验失败，推荐用整数单位或JS兜底校验。
step属性在里怎么起作用
它只对 type="number" 和 type="date"（以及部分浏览器支持的 type="time"）生效，对 type="text" 或其他类型完全无效。浏览器会用它约束用户输入值、限制上下箭头点击的增量、影响表单验证逻辑。
常见错误是给 step 设成 0.1 却发现输入 0.3 时校验失败——这不是 bug，而是浮点精度问题导致的底层比较偏差。
-
step默认值是1，不是any - 设为
step="any"表示允许任意数值（跳过步长限制），但不等于关闭验证——仍需满足min/max - 若未指定
min，浏览器通常从0开始计算合法值（如step="0.5"时，-0.5不会被自动允许）
为什么0.1步长经常校验失败
因为 step="0.1" 实际触发的是二进制浮点数比较，而 0.1 在 IEEE 754 中无法精确表示。浏览器内部用 (value - min) % step === 0 判断合法性，结果可能为 false。
解决办法不是硬调 step，而是换思路：
立即学习“前端免费学习笔记（深入）”；
- 用整数单位 + 单位换算：比如金额用“分”存储，
step="1"，显示时除以100 - 改用
step="0.01"配合min="0"，再配合 JS 格式化显示（避免用户直接输0.1） - 禁用原生验证，用 JS 手动校验：
Math.abs((value - min) % step)
和min/max一起用时的隐含规则
min 和 step 共同决定第一个合法值。例如 min="10" step="3"，合法值是 10, 13, 16, 19...；但若 min="11" step="3"，第一个合法值其实是 12（因为 11 不满足 (11 - 11) % 3 === 0？错——实际是浏览器会向上取最近的合法起点，即 12）。
- 浏览器不保证
min本身合法，它只是下界 -
max同理，合法值不会超过max，但最后一个值未必等于max - 若
min、max、step三者矛盾（如min="1" max="2" step="0.3"），部分浏览器会忽略step验证，仅保留 UI 增量行为
移动端和无障碍场景下的实际表现
iOS Safari 的数字键盘不随 step 变化，始终只提供整数键；Android Chrome 会显示小数点，但长按小数点后只能输一位——step="0.01" 在这种环境下几乎无意义。
屏幕阅读器一般不播报 step 值，也不会提示“当前值不符合步长”，只会读出 min/max 和当前值。真正影响可访问性的，是是否设置了 aria-valuetext 或用 JS 动态更新提示。
- 别依赖
step实现业务级精度控制，它只是辅助约束 - 服务端必须重做校验，不能信前端
checkValidity()结果 - 如果需要强制两位小数，用
inputmode="decimal"+ JS 截断 +toFixed(2)更可靠
