step 属性仅对 type="number"、"range"、"datetime-local"、"date"、"time"、"month"、"week" 有效；在 type="text" 或 "email" 上无效，且 type="date" 的 step 多数浏览器忽略，type="datetime-local" 的 step 单位为秒且只接受整数。
step 属性只对哪些 type 生效
它只在 type="number"、type="range"、type="datetime-local"、type="date"、type="time"、type="month"、type="week" 上起作用；写在 type="text" 或 type="email" 上，浏览器会解析但完全忽略——没有上下箭头、不触发校验、stepUp() 报错或静默失败。
常见误用：<input type="text" step="0.01"> 看似想控小数精度，实则无效。必须明确设为 type="number" 才能激活步进逻辑。
-
type="date"的step被大多数浏览器忽略：无论设step="7"还是step="1"，日期选择器始终按天跳转，无法实现“每周一”选值 -
type="datetime-local"的step单位是秒，且只接受整数（如step="60"表示 1 分钟），设step="30.5"会被截断为30 -
type="range"支持step，但它只定义滑块合法停靠点，不影响拖动过程中的视觉精度；用户拖到中间松手，浏览器会自动对齐到最近的min + n × step值
step="0.1" 为什么输入 0.15 会变成 0.2
这不是拦截，而是浏览器的自动矫正行为：当用户手动输入不符合步长规则的值（如 step="0.1" 下输 0.15），失焦或提交时，Chrome/Firefox 会四舍五入到最近的合法值（0.2）；Safari 可能直接截断为 0.1。这个动作不可禁用，也不触发 input 事件。
根本原因在于浮点精度：二进制无法精确表示 0.1，旧版 Chrome 甚至会把 step="0.1" 当作 step="1" 处理。
- 安全做法是换单位：金额用“分”，设
min="100"、step="1"、value="199"表示 1.99 元 - 必须用小数时，统一补零：
min="0.00"、max="10.00"、step="0.01"，避免min="0"和step="0.01"混用 - 别自己写
parseFloat(val) + 0.1，改用原生input.stepUp(1)，它严格按当前step执行，不引入 JS 浮点误差
step="any" 的真实效果和风险
step="any" 不是“放开所有限制”，而是禁用步长对齐逻辑：上下箭头和 stepUp() 全部退化为 ±1 整数增减（value="1.5" 点 ↑ 变成 2.5，不是 1.6）；表单提交时不再检查 validity.stepMismatch，但依然校验是否为合法数字（"abc" 仍报错）。
它适合需要任意精度输入（如地理坐标、科学数据）又想保留原生 spinner 的场景，不是偷懒的“关闭校验”方案。
- 旧版 Safari（≤15.4）直接忽略
step="any"，仍按step="1"校验，小数输入可能被清空 - 手动输入
"1.23456789"完全允许，提交前不报错——业务逻辑必须靠 JS 或后端兜底 -
valueAsNumber仍走 IEEE 754 解析，"0.1"读出来还是0.10000000000000001，step="any"不解决浮点精度问题
动态修改 step 后 value 失效或卡顿
直接赋值 input.step = "0.25" 不可靠：浏览器不会自动重算当前 value 是否合法，旧值很可能已越界，导致 spinner 点不动、滑块拖卡、stepUp() 报错。
正确做法是改完 step 后立刻重置 value，并主动校验：
- 用
el.setAttribute("step", "0.25")替代直接赋值，部分浏览器响应更稳定 - 紧接着执行：
el.value = (Math.round(parseFloat(el.value) / 0.25) * 0.25).toFixed(2) - 调用
el.checkValidity()主动触发校验，必要时el.reportValidity()提示用户 - 连续切换
step时，加requestAnimationFrame(() => { /* reset logic */ })避免状态残留
真正麻烦的从来不是写 step，而是用户粘贴、拖拽滚动条、第三方输入法——这些行为完全绕过 step 约束，它只管受控增减，不管自由输入。
