浏览器校验input合法值时，实际检查value是否属于min + n×step（n为整数）且≤max，而非仅value≤max；若max不落在该等差数列上，则取小于等于max的最大合法值，如min="1" step="2" max="10"时最大合法值为9。
step 和 max 必须从 min 出发构成等差数列
浏览器校验合法值时，不是简单判断 value ，而是检查该值是否属于序列 <code>min + n × step（n 为整数）且 ≤ max。如果 min 本身不满足这个序列起点要求，max 就会“失效”——比如 min="1" step="2" max="10"，实际最大合法值是 9，不是 10，因为 1 + 4×2 = 9，而 1 + 5×2 = 11 > 10。
常见错误现象：value="10" 在提交时被标红，提示“值不符合要求”，即使它明显 ≤ max。
- 显式对齐起点：若要包含 10，应设
min="0" step="2" max="10"或min="2" step="2" max="10" - 避免用整数
min搭配小数step（如min="1" step="0.5"），部分 Safari 会静默忽略超出序列的初始值 - 调试时可快速验证：在控制台运行
Array.from({length: 10}, (_, i) => min + i * step).filter(x => x ，看真实生成的合法值列表
max 超出 step 序列终点时会被截断
max 不是“软上限”，而是硬性边界；但它的生效前提是存在某个整数 n，使得 min + n × step === max。否则，浏览器取小于等于 max 的最大合法值——这个值由步进逻辑决定，不是你写的 max 字面值。
使用场景：做音量滑块（0–100，步长 5）、库存数量选择（0–999，步长 1）等固定粒度控制。
立即学习“前端免费学习笔记（深入）”；
-
<input type="range" min="0" max="100" step="5">→ 合法值：0, 5, 10, ..., 100（刚好整除） -
<input type="number" min="0" max="100" step="7">→ 最大合法值是 98（0 + 14×7），100 被排除 - 若需强制支持 100，且不能改
step，就只能调高max到下一个合法点（如设max="105"），再用 JS 截断显示或提交值
动态修改 step 后，max 不会自动重算合法范围
用 JavaScript 改 step 时，max 的数值不变，但它的语义已变——原来合法的 value 可能瞬间越界，甚至导致 checkValidity() 返回 false。
容易踩的坑：用户正在拖动滑块，你突然改了 step，滑块“卡住”或跳回起点。
- 必须同步重置
value：先计算最近合法值，如inputEl.value = Math.round(inputEl.value / newStep) * newStep - 不能直接赋值
inputEl.step = "0.1"，要用inputEl.setAttribute('step', '0.1')，否则部分浏览器不触发重校验 - 如果
max是动态计算的（如根据数据上限生成），每次改step后也应重新设置max，确保它落在新序列内
小数 step + max 组合时，浮点误差会让边界模糊
设 min="0" max="1" step="0.1"，理论上应有 11 个点（0.0, 0.1, ..., 1.0），但因 IEEE 754 表示误差，某些浏览器内部生成的最后一个值可能是 "0.9999999999999999"，导致 value="1" 被判非法。
性能 / 兼容性影响：旧版 Safari（≤15.4）对小数 step 支持极不稳定，max 可能完全不参与校验。
- 优先用整数单位：如调节百分比，设
min="0" max="100" step="1"，显示时除以 100 - 若必须用小数，统一写三位小数：
min="0.000" max="1.000" step="0.001"，减少隐式精度推导差异 - 服务端永远要重新解析并校验，不能信任前端
max的截断效果——尤其当max来自用户输入或 API 响应时
真正难处理的不是怎么写，而是浏览器对 min、step、max 三者关系的隐式校验逻辑：它不报错，不警告，只是悄悄把你的 value 往最近合法点拉，直到你发现滑块拖不动、输入被清空、表单提交失败。
