很多开发者在操作 HTML input 的 step 属性时，往往会掉进一个常见陷阱：试图用 step 控制数字输入精度，却在 type="text" 上毫无作用；或者在 type="number" 中多次点击 ↑ 后，数值不仅未按预期步进，反而出现 0.30000000000000004 这样的浮点尾巴。严格来说，这并非程序缺陷，而是 HTML 规范在设计之初就定下的规则——只不过不少开发者习惯性忽略了这些细节。
step 属性只对哪些 type 生效
只有 type="number"、type="range"、type="datetime-local" 这三类 input 才会真正识别 step 属性。如果将 step 写在 type="text" 或 type="email" 上，浏览器虽然会解析该属性，但在执行时完全忽略——不会显示增减按钮，键盘上下键无效，表单校验也不会触发。一个典型的错误写法是：，看起来像是要控制输入精度，但浏览器仅将其当作普通文本框处理，相当于做了无用功。
step="0.1" 为什么点两次 ↑ 变成 0.30000000000000004
这本质上不是 bug，而是浮点数在二进制中无法精确表示 0.1，底层计算残留了微小误差。更早些的 Chrome 版本还有一个更令人困惑的行为：静默地将 step="0.1" 当作 step="1" 处理。因此，解决方案并非单纯对抗浮点运算——
- 在金额类场景中，建议统一以“分”为单位存储：设置
min="100"、step="1"、value="199"，前端显示时再除以 100 转换为 1.99 元，后端处理也更省心。 - 如果必须使用小数，请显式写满位数：例如
min="0.00"、max="10.00"、step="0.01"，避免将min="0"与step="0.01"混用，以免引发意外。 - 不要自行编写
parseFloat(val) + 0.1这类运算，推荐直接使用原生的input.stepUp(1)方法。它会严格依据当前 step 值执行，不会引入 JavaScript 浮点误差，既干净又高效。
value 初始值不匹配 step 就会卡住
step 属性并非独立开关，它与 min、value 共同构成一个数学约束：value 必须等于 min + n × step（n 为整数）。一旦不满足此条件，浏览器会静默修正——例如滑块拖不动、点 ↑ 跳到非预期值、增减按钮失灵，十有八九是卡在此处。
举例来说：min="1"、step="0.3"，你设了 value="1.0"，Chrome 可能悄悄改为 1.2，或直接禁用控件。安全的写法是 min="0.0"、step="0.1"，那么 value 必须是 "0.0"、"0.1"、"0.2" 其中之一，不能随意赋值。
如果你动态修改了 step，务必要立即重置 value：input.value = (Math.round(parseFloat(input.value) / newStep) * newStep).toFixed(2)，这个步骤不能省略。
step="any" 不是“不限制”，而是“退化为 ±1”
很多人误以为 step="any" 会解除所有限制，其实不然。它仅仅禁用了步长对齐逻辑——
- 上下箭头以及
stepUp()方法全部降级为整数增减：例如当前value="1.5"，点 ↑ 会变成 2.5，而非 1.6。 - 浏览器仍然会校验输入是否为合法数字（不能输入
"abc"），但不再触发validity.stepMismatch校验错误。 - 手动输入
"1.23456789"完全允许，表单提交前也不会报错——业务上必须依靠 JavaScript 或后端来兜底检查。 - 它适合需要任意精度输入的场景（如坐标、科学数据），同时保留原生增减按钮，但绝不是偷懒“关闭校验”的替代方案。
坦白说，最麻烦的从来不是设置 step 本身，而是用户粘贴数据、拖拽滚动条、使用第三方输入法输入——这些行为完全绕过了 step 的约束。step 只负责受控的增减操作，从未限制用户的自由输入。因此，不要指望仅靠它解决所有精度问题，该加的后端校验还是得加上。