step仅对type="number"等少数类型生效，以min为起点校验(value−min)%step===0，浮点精度需警惕，step="any"不禁用所有校验，JS动态修改需同步重置value并调用checkValidity。
step 属性不是输入过滤器，也不是四舍五入开关，它只在特定条件下起作用：约束微调行为 + 参与原生校验。
哪些 type 才会触发 step 行为
只有 type="number"、type="range"、type="date"、type="time" 等少数类型识别 step；写成 type="text" 或 type="email" 时，该属性被完全忽略，浏览器既不报错也不生效。
常见错误现象：
- 给
加了 step，但上下箭头没反应、提交也不校验 - 移动端用
type="tel"想控制数字步进，结果 step 形同虚设
step 的合法性判断逻辑是 (value − min) % step === 0
浏览器不是简单看 “value 是否能被 step 整除”，而是以 min 为起点构建等差数列：min、min + step、min + 2 × step……合法值必须落在这个序列里。
这意味着：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
-
min="1" step="0.3"时，value="1.0"实际非法（因为 1.0 − 1 = 0，0 % 0.3 在浮点下不恒为 0），部分浏览器会静默修正为 1.2 或 0.9 -
min="0.00" step="0.01"是安全组合；但min="0" step="0.01"容易因隐式类型转换导致校验失败 - 金额类场景强烈建议用整数单位：设
min="0" step="1" value="199"表示 1.99 元，彻底避开浮点精度陷阱
step="any" 并不等于“完全放开”
step="any" 仅禁用步长对齐逻辑，但其他约束依然存在：
- 上下箭头和
stepUp()/stepDown()仍按 ±1 增减（不是 ±0.1） - 手动输入
3.1415926不会触发validity.stepMismatch，但输入abc仍会报validity.badInput - 表单提交时不再校验步长，但
min/max校验照常生效 - 它无法防御粘贴、拖拽滚动条、第三方输入法等绕过原生交互的操作
JS 赋值或动态改 step 时的坑
通过 JavaScript 修改 value 或 step，浏览器不会自动重算合法性，极易引发跳变、卡顿或校验失效：
- 直接写
input.value = "2.05"，再点 ↑，可能跳到 3.05（而非预期的 2.15），因为浏览器仍按旧 step 计算 - 执行
input.step = "0.25"后，旧value很可能已越界，需同步重置：input.value = (Math.round(parseFloat(input.value) / 0.25) * 0.25).toFixed(2) - 推荐用
input.setAttribute("step", "0.25")替代直接赋值，兼容性更稳 - 改完务必调用
input.checkValidity()，必要时input.reportValidity()主动提示用户
真正麻烦的从来不是写对 step，而是用户各种非标准操作——粘贴、长按拖动、语音输入、外接设备模拟按键——这些地方 step 根本不参与约束，业务强校验必须靠 JS 和后端兜底。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
