type="number"的step严格控制增减步长并参与校验；type="range"仅决定停靠点；type="time"/"datetime-local"以秒为单位且需整数；type="date"的step基本无效。

type="number" 的 step 是最严格也最常用的情况

它直接控制上下箭头、方向键增减、stepUp() 和 stepDown() 的步长，同时参与原生表单校验：validity.stepMismatch 会在提交时触发。但要注意：手动输入非法值（如 step="0.1" 下输 "0.15"）不会实时拦截，失焦或提交时才四舍五入（Chrome/Firefox）或截断（Safari），且这个过程不触发 input 事件。

常见坑点：

• min 和 step 小数位不一致会导致合法值漂移，比如 min="1" + step="0.01"，浏览器可能允许 value="1"，但第一次点 ↑ 会跳到 1.01，而非你预期的 1.00
• 浮点精度问题真实存在：step="0.1" 在部分旧版 Chrome 中曾被当作 step="1" 处理；建议金额类用整数单位（如分），写成 min="100"、step="1"
• 不写 step 时，Chrome 会根据 min 推导（如 min="0.5" → 默认 step="0.5"），Firefox 则默认 step="1"，跨浏览器行为不一致，必须显式声明

type="range" 的 step 只影响“停靠点”，不影响拖动过程

滑块拖动时视觉上可以停在任意位置，但松手后浏览器会自动对齐到最近的合法值（min + n × step）。也就是说，step 不控制拖动精度，只决定最终取值集合。

典型使用场景和限制：

立即学习“前端免费学习笔记（深入）”；

• 若 min="0"、max="100"、step="25"，合法停靠点只有 0、25、50、75、100，中间值（如 37）会被修正
• UI 上不会自动标注刻度，需要 JS + CSS 手动实现标尺或实时格式化显示
• 移动端 Safari 支持良好，但旧版 Android WebView 可能完全忽略 step，需降级处理

type="time" 和 type="datetime-local" 的 step 单位是秒且必须为整数

step 对 time 类型代表“秒数”，不是分钟。写 step="15" 是 15 秒，不是 15 分钟——这是最常见的配置错误。

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

正确换算方式：

• 每 1 分钟可选 → step="60"
• 每 5 分钟可选 → step="300"
• 每 15 分钟可选 → step="900"
• datetime-local 同样以秒为单位，且只接受整数，step="30.5" 会被截断为 30

另外，time 输入框的默认值（value）建议显式设为秒数为 0 的时间，如 "09:00"，否则某些浏览器可能在加载时静默修正或显示异常。

type="date" 的 step 基本无效，别依赖它做周/月粒度控制

虽然规范说 step 支持 date，但现实中绝大多数浏览器（Chrome、Firefox、Edge）都忽略它。无论你写 step="7" 还是 step="1"，日期选择器始终按天跳转，无法实现“每周一”或“每月1号”的强制约束。

如果你真需要周粒度选择，可行方案只有两个：

• 放弃原生 date，改用自定义日历组件（JS 实现逻辑 + UI 控制）
• 保留 type="date"，但用 JS 监听 change 事件，检查日期是否为周一（new Date().getDay() === 1），不合规则重置或报错

同理，month 和 week 虽然理论上支持 step，但实际兼容性和行为一致性极差，生产环境慎用。