动态切换 input 的 step 属性需用 setAttribute 并重算 value，避免跳变；step="any" 实为整数步进，非任意精度；小数步长须对齐初始值，移动端 range 的 step 支持差，应优先用 button+number 组合。
动态切换 step 属性后 input 失效或跳变
直接改 input.step = "0.5" 几乎总出问题：旧 value 很可能已不满足新步长的数学约束（即不再符合 min + n × step），浏览器不会自动重算，导致 spinner 卡死、拖动跳回、点 ↑ 没反应。
必须用 setAttribute 并立刻重置 value：
-
input.setAttribute('step', '0.25')—— 比直接赋值更可靠，尤其在 Safari 和旧版 Chrome 中 - 紧跟着重算合法值：
input.value = (Math.round(parseFloat(input.value) / 0.25) * 0.25).toFixed(2) - 若连续切换（如从 0.01 → 1 → 0.5），建议包一层
requestAnimationFrame避免 DOM 状态残留 - 调用
input.checkValidity()主动触发校验，必要时input.reportValidity()提示用户
step="any" 不是“关闭校验”，而是退化为整数步进
设 step="any" 后，上下箭头和 stepUp() 全部变成 ±1 整数增减，哪怕当前值是 3.14，点 ↑ 也会变成 4.14（不是 3.15）。它只禁用 validity.stepMismatch，其他校验照常（比如非数字输入仍报错）。
真正需要任意精度时，别依赖 step="any"，而应：
立即学习“前端免费学习笔记（深入）”；
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 用
type="text"+ 自定义 JS 校验，或保留type="number"但彻底接管增减逻辑 - 所有加减操作统一走
input.stepUp(1)/input.stepDown(1)，它们严格按当前step执行，不引入浮点误差 - 手动输入、粘贴、拖拽滑块等行为完全绕过
step约束——业务层必须用input或change事件做兜底校验
小数步长必须对齐初始值，否则静默修正会破坏体验
浏览器对 value 的合法性检查是静默的：如果 min="0"、step="0.1"，但 value="0.05"，Chrome 可能悄悄改成 0 或 0.1，DOM 中看不出变化，但后续 stepUp() 会从修正后的值开始算，造成用户感知错乱。
安全做法：
- 金额类一律用“分”：
min="100"、step="1"、value="199"表示 1.99 元 - 必须用小数时，统一补零：
min="0.00"、max="10.00"、step="0.01"，且value显式写成"1.99"（不是1.99） - 动态切换前，先用
parseFloat(input.value)转成数字再参与计算，避免字符串拼接导致意外
移动端滑块（type="range"）的 step 支持极不稳定
iOS Safari 对 step 小于 0.1 的支持几乎不可靠，部分版本直接降级为 step="1"；Android 厂商定制浏览器也常忽略小数 step。滑块本身不渲染刻度，所谓“精度”只是松手瞬间的数学对齐，用户根本看不到停靠点。
替代方案更实际：
- 放弃
type="range"，改用两个button+input[type="number"]组合，可控性高得多 - 若坚持用滑块，
step只设整数（如1或5），视觉精度靠 CSS 刻度条 + JS 映射实现 - 所有滑块值变更必须监听
input事件（不是change），因为用户拖动过程中就需实时响应
最麻烦的从来不是切 step，而是用户粘贴、第三方输入法、拖拽滚动条——这些行为完全绕过所有原生约束，step 在它们面前形同虚设。
