step 属性仅在手动输入或点击箭头时生效，且因浏览器解析差异和浮点数精度问题（如 step="0.1" 无法输入 0.3），导致兼容性差；应优先用 step="any" 配合 JS 校验，并确保 min 是 step 的整数倍，移动端需额外监听 input 或 blur 事件校验。
step 属性不是万能的数字约束开关，它只在用户手动输入或点击上下箭头时起作用，且浏览器对它的解析存在明显差异。
为什么设置了 step="0.1" 却无法输入 0.3？
这是最常被忽略的兼容性问题：Chrome 和 Edge 默认启用原生数字输入控件（带上下箭头），它们会严格校验输入值是否符合 step 规则；但 Safari 和 Firefox 不强制拦截非法输入，仅在表单提交时校验。更关键的是，step 的计算基于浮点数二进制表示，0.1 在 IEEE 754 中无法精确存储，导致某些“看似合法”的值（如 0.3）被判定为不匹配。
实操建议：
- 优先用
step="any"配合 JavaScript 校验，而非依赖原生行为 - 若必须用固定步长，选能精确表示的值，如
step="0.125"（1/8）、step="0.25"（1/4） - 测试时务必在 Safari 和 Chrome 中分别验证输入流程，不要只看提交报错
step 与 min/max 的配合陷阱
step 不是独立生效的，它和 min 共同决定第一个合法值：首个合法值 = min 向上取整到最近的 step 倍数。例如 min="0.2" step="0.1"，合法起点是 0.2；但 min="0.21" step="0.1"，首个合法值其实是 0.3（因为 0.21 不是 0.1 的整数倍）。
立即学习“前端免费学习笔记（深入）”；
常见错误现象：用户输入 0.21 后失去焦点，值自动跳变为 0.3 或清空 —— 这是 Chrome 的自动修正行为，不可禁用。
实操建议：
- 确保
min是step的整数倍，例如min="0.2" step="0.1"或min="0" step="0.1" - 避免用
min="1"+step="0.3"这类组合，首个合法值会是1.2，造成体验断层 - 若需宽松范围控制，改用
pattern+ JS，而非强依赖min+step
移动端数字键盘不触发 step 校验的原因
iOS 和 Android 原生软键盘在 type="number" 下仅提供数字键，但不会主动执行 step 约束逻辑。用户可直接输入任意数字串（如 1.2345），直到 blur 或 submit 才触发校验。这意味着你看到的“允许输入”，其实只是界面没拦，不代表值合法。
性能与兼容性影响：依赖 step 做业务逻辑判断（比如动态计算价格）极易出错，因为 input.value 在中间状态可能是非法值。
实操建议：
- 所有涉及
step的计算逻辑，必须包裹在checkValidity()或自定义校验函数中 - 监听
input事件做实时格式化（如四舍五入到最近step值），但注意不要破坏用户编辑意图 - 对关键字段（如金额、库存），服务端必须重复校验，不能信任前端
step结果
真正难处理的不是怎么写 step，而是它在不同环节（输入、失焦、提交、移动端软键盘）表现不一致，且无法通过 CSS 或属性开关统一行为。别把它当控制逻辑用，只当作辅助提示更稳妥。
