step 和 max 必须同时设置，否则浏览器会静默修正 value；value 必须满足 value === min + n × step（n 为整数），否则加载时被重置为最近合法值。
step 和 max 必须一起设，否则浏览器可能静默修正 value
只写 max="100" 不设 step，或只写 step="5" 不写 max，value 初始值就容易被浏览器悄悄改掉。比如 <input type="number" min="0" max="100" step="5" value="7">，浏览器会把 value 强制变成 5（最近的合法值），但页面上不报错、也不提示——你拖不动、点+号跳到 10 而不是 12，问题就出在这儿。
-
value必须满足：value === min + n × step（n是整数），否则加载时就被重置 -
max不是“软上限”：用户手动输入超限值（如max="100"却输 101），表单提交前会触发validity.rangeOverflow错误 - 若
min="0" step="5"，则max必须是 5 的倍数（如 95、100、105），否则最后一个合法值可能被截断（例如max="97"时，95 是最后一个可选值，97 不合法）
range 滑块里 step 决定“能停在哪”，max 决定“能滑多远”
对 <input type="range"> 来说，max 定义轨道右端点，step 决定滑块能卡住的所有位置。二者共同生成一个离散集合：从 min 开始，每次加 step，直到 ≤ max。比如 min="0" max="10" step="3"，合法值只有 0、3、6、9 —— 滑块永远停不到 10。
- 别指望
step="1"+max="100"就能自然显示百分比刻度；浏览器不自动画刻度线，得靠 CSS 或 JS 模拟 - 移动端触摸滑动时，
input事件仍可能上报非步长倍数的中间值（如value="4.82"），需在 JS 中用Math.round(value / step) * step主动对齐 -
step="any"会让max变成纯视觉边界：滑块能拖到任意浮点值，但checkValidity()不再校验步长，只看是否超max
常见错误：max 和 step 数值类型不一致引发精度断裂
写 min="0" max="10" step="0.1" 看似合理，但二进制浮点误差会让某些浏览器把 0.1 解析为 0.10000000149...，导致第 10 次累加后超出 max。用户拖到尽头发现卡在 9.9，而不是 10。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 金额类场景优先用整数单位：
min="0" max="1000" step="1"（单位“分”），显示时除以 100 - 必须用小数时，统一小数位数：
min="0.00" max="10.00" step="0.01"，避免浏览器内部类型转换混乱 - 监听
input事件时，别直接用parseInt(e.target.value)，它会截断小数；用parseFloat()后再做toFixed(2)格式化
表单验证失败时，max 和 step 触发不同错误类型
用户输入超限值，浏览器原生验证会抛出具体错误码，不是笼统的“无效”。这直接影响你用 JS 做针对性提示的方式。
立即学习“前端免费学习笔记（深入）”；
- 输入 105 且
max="100"→input.validity.rangeOverflow === true - 输入 7.3 且
step="0.5"→input.validity.stepMismatch === true - 两者同时违规（如
max="10" step="3"下输入 12）→rangeOverflow优先级更高，stepMismatch不会触发 - 用
reportValidity()手动触发校验时，错误信息文案由浏览器决定，无法自定义；如需统一提示，建议禁用原生验证（novalidate）后全由 JS 控制
实际用起来最易忽略的一点：max 和 step 的数值必须在 DOM 加载完成、所有属性解析完毕后才真正生效。如果 JS 动态设置 max 但没同步重算 value 是否仍在合法集内，滑块就会卡死或跳变。
