step 属性仅控制 number 类型输入框的受控增减（如箭头、方向键、stepup/down）的最小变化量，不阻止手动输入任意值，也不影响提交校验，除非配合 min/max 使用原生约束验证。
step 属性对 type="number" 的实际控制效果
step 控制的是用户点击上下箭头、用键盘方向键增减，或调用 input.stepUp()/input.stepDown() 时的最小变化量。它不阻止手动输入任意值，也不影响表单提交校验——除非配合 min 和 max 使用 checkValidity() 或原生约束验证。
常见错误是以为设了 step="0.5" 就能禁止输入 1.23：不会。浏览器只在“受控增减”时遵循 step，手动输入仍自由。
-
step值必须是数字（如"1"、"0.01"），不能是"any"以外的字符串；"any"表示不限制步进（但依然允许任意输入） - 若未指定
step，默认为1（整数步进）；设为0.1后，input.stepUp()会从1.0变成1.1，而非1.1000000000000001（现代浏览器已做浮点修正） - 当
value初始值不满足min + n × step规则时，Chrome/Firefox 会在提交前报ValidityState.stepMismatch === true，但 Safari 旧版本可能忽略
日期类 input（type="date"、type="datetime-local"）的 step 行为限制
step 对日期类型仅在 type="datetime-local" 中有明确定义作用：它表示秒级步进（单位为秒），且**必须是整数**。对 type="date"、type="month"、type="week"，step 属性被完全忽略——浏览器不实现任何步进逻辑，上下箭头始终按天/月/周移动，无法更改。
例如：<input type="datetime-local" step="3600"> 表示每次增减 1 小时；设 step="60" 即 1 分钟；设 step="1" 才支持秒级调整。若设 step="30.5"，会被截断为 30（非四舍五入）。
-
type="date"永远按“天”步进，无论 step 值是多少，包括step="7"也不会跳周 - 移动端 iOS 的 datetime-local 输入框常绕过 step（直接弹原生时间选择器），实际步进由系统控件决定，不可靠
- 想实现“每周一”的日期选择？不能靠
step，得用 JS 监听input事件并手动矫正 value
浏览器兼容性与验证绕过的现实问题
原生 step 验证在部分场景下形同虚设：用户粘贴非法值（如 "2.7" 到 step="0.5" 的 number 输入框）、用开发者工具改 DOM、或禁用 JS 后绕过前端校验。真正的约束必须落在服务端或通过 JS 主动干预。
- 触发验证需显式调用
input.reportValidity()或提交表单；单纯 blur 不触发 stepMismatch - Firefox 对
step="any"支持较晚（v73+），旧版会退化为step="1" - 某些安卓 WebView（如微信内置）对
datetime-local的step完全不响应，建议降级为两个分离的date+time输入
替代方案：用 JS 实现可靠步进控制
当原生 step 不够用（比如需要“每 15 分钟”但 type=datetime-local 在 iOS 失效），就得自己接管增减逻辑。核心是监听 input 和 keydown，再用 Date 或 parseFloat + 四舍五入对齐步长。
例如强制 number 输入框只接受 0.25 的倍数：
input.addEventListener('input', () => {
const val = parseFloat(input.value);
if (!isNaN(val)) {
input.value = Math.round(val * 4) / 4; // 对齐 0.25 步长
}
});
注意：直接修改 value 会触发新一轮 input 事件，需加防抖或标记位避免死循环；日期对齐更复杂，涉及时区和 DST，别依赖 new Date().setMinutes() 简单处理。
真正难的不是写这十几行 JS，而是想清楚——你到底要约束用户输入，还是只优化交互体验？前者必须后端兜底，后者才适合用 step 或轻量 JS。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
