step属性仅约束合法值集合而不驱动实时步进，合法值由min + n × step生成且需≤max，初始value不满足时浏览器会静默修正，移动端软键盘常忽略step，非线性步进需用索引映射数组实现。
step 属性不驱动实时步进，只约束合法值集合
step 属性本身不“驱动”任何行为，它只是声明一个静态规则：哪些数值在当前 min/max 范围内是合法的。浏览器用它决定上下箭头怎么跳、提交时是否报 stepMismatch，但不会主动监听或修正输入过程中的中间值。
常见错误现象：设了 step="0.1"，用户输 0.15 不报错，拖动滑块仍能停在 0.12 —— 这不是 bug，是预期行为。因为 step 不拦截 input 事件，也不实时截断。
- 合法值由公式生成：
min + n × step（n为整数），且必须 ≤max - 初始
value必须满足该公式，否则 Chrome/Safari 会静默重写（比如value="1.05"+step="0.1"可能变成1.0或1.1） - 移动端软键盘常忽略
step，尤其 iOS Safari 的数字键盘不显示小数点，step="0.1"形同虚设
用 input[type="range"] 实现可预测的非线性步进
想让滑块“跳”到预设档位（如 1→2→5→10→20），不能靠 step，得用索引映射。核心是把滑块当选择器，而非数值输入器。
正确做法：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 定义升序数组：
const values = [1, 2, 5, 10, 20]; -
<input type="range" min="0" max="4" step="1">（max = values.length - 1） - 监听
input事件：const actual = values[slider.valueAsNumber]; - 同步更新
<output>或隐藏的<input type="number">，并设aria-valuetext描述语义（如 “中等增益”）
注意：仅监听 change 会导致拖动过程中无反馈；键盘操作（←→/PageUp/PageDown）也必须走同一映射逻辑，否则体验割裂。
type="number" 中 step="0.1" 失效的真正原因
不是浏览器不支持，而是 IEEE 754 浮点精度缺陷：0.1 在二进制里无法精确表示。旧版 Chrome 甚至会把 step="0.1" 四舍五入成 step="1"，导致所有增减都按整数跳。
可靠方案：
- 金额类场景统一换算单位：
min="199"、step="1"、value="199"表示 1.99 元 - 避免混用整数与小数：
min="0.00"、max="10.00"、step="0.01" - 动态改
step后，必须重置value：input.value = (Math.round(parseFloat(input.value) / newStep) * newStep).toFixed(2) - 别信
step="0.10"能修复——这只是某些浏览器对末尾零更敏感的临时缓解
需要实时精度控制时，step 只是辅助，JS 才是主力
音频进度条、测量仪器配置这类场景，用户拖动滑块要精确到毫秒级，step 仅负责划定最小粒度（如 step="0.01"），真正起作用的是 JS 映射逻辑：
- 确保
max设为audio.duration，且在loadedmetadata后设置，否则max=0导致滑块失效 - 用
input事件（非change）实时响应：audio.currentTime = parseFloat(slider.value); - 防抖处理频繁 seek：
setTimeout(() => { audio.currentTime = ... }, 50) - 移动端加
touch-action: none防止误触发页面滚动
最易被忽略的一点：step 再小，如果没配 requestAnimationFrame 同步更新滑块 UI，视觉上依然卡顿——精度是数值的，顺滑是帧率的，两者缺一不可。
