step 属性仅约束微调按钮和表单提交校验，非输入过滤器或四舍五入开关；仅对 type="number"、"range"、"date"、"time" 等生效；需与 min/max 协同，依据 (value−min)%step===0 判断合法性；浮点精度问题易致异常，金额应使用整数单位；强约束须依赖 JS 和后端兜底。
step 属性不阻止用户输入非法值，只约束原生微调按钮行为和表单提交时的校验逻辑。 它不是输入过滤器，也不是四舍五入开关，更不是服务端安全机制——把它当“提示+轻量验证”用才不会踩坑。
step 只对特定 type 生效，写错类型等于白写
它只在 type="number"、type="range"、type="date"、type="time" 等有限类型中起作用。写成 type="text" 或 type="email" 时，step 完全被浏览器忽略，连警告都不会有。
-
type="number"：步长影响上下箭头、键盘上下键、以及checkValidity()的stepMismatch判断 -
type="range"：滑块松手后会自动吸附到最近合法刻度点，不是视觉参考线 -
type="date"：只接受整数step（如step="7"表示以周为单位），step="0.5"会被静默忽略 - 写成
step="0,5"（逗号小数点）或step="1.00"（末尾零）不影响解析，但step="any"必须是字符串字面量，不能是变量或数字
min/max/step 三者必须协同，否则规则失效
浏览器判断一个值是否合法，依据的是 (value - min) % step === 0 且 min ≤ value ≤ max。只要其中任一条件不满足，input.validity.stepMismatch 就为 true。
-
min="1" step="0.3"：理论上第一个合法值是 1.2（因为 1 + 0.3 = 1.3？错），实际从 min 开始向上找第一个能被 step 整除的偏移值，部分浏览器会允许 1 输入但箭头跳到 1.2 —— 这不是 bug，是规范允许的实现差异 -
min="0" max="1" step="0.3"：合法值只有 0、0.3、0.6、0.9；1 不合法（因为(1 - 0) % 0.3 !== 0） - 初始
value="3.14159"配step="0.01"：加载即触发stepMismatch，表单默认 invalid，需提前处理或改用step="any"
浮点精度问题会让 step="0.1" 表现诡异
0.1 在二进制浮点中无法精确表示，导致计算误差累积。你看到的 0.30000000000000004 不是 step 的错，而是 JavaScript 数值模型的固有特性。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 用
step="0.1"时，上下箭头可能跳变异常（比如从 0.7 直接到 0.9），尤其在 Safari 中更明显 - 金额类场景务必用整数处理：
step="1"+ 单位“分”，而非step="0.01"+ “元” - 若必须支持小数输入，
step="any"更可控——把精度校验交给 JS，例如监听blur后用parseFloat(value).toFixed(2)格式化 - 动态修改
input.step后，input.validity.stepMismatch不会自动更新，得手动调用input.checkValidity()或赋值触发重解析
移动端和旧浏览器的 step 行为差异极大
iOS Safari 的数字软键盘不一定显示小数点，Android 旧版 WebView 可能完全忽略 step —— 所有这些，都不能靠 CSS 或属性本身修复。
- 用户粘贴
"1.2345"进step="0.01"输入框，浏览器不会拦截，也不会自动截断；只有提交时才报错 -
step="any"在某些 Safari 版本中会使上下箭头退化为 ±1 步进，失去精度控制意义 - 所有浏览器都不校验
valueAsNumber，它只做字符串转数字，完全无视step、min、max - 真正需要强约束的场景，必须配合 JS：监听
blur做格式化，监听submit做二次校验，后端永远要做最终兜底
最常被忽略的一点：step 不改变 input 的 value 字符串内容，也不触发任何事件；它只是让浏览器在特定时机（点击箭头、按上下键、提交）多做一次数学判断。别指望它替你做数据清洗或精度控制。
