只有type="number"、type="range"、type="datetime-local"响应step；type="text"等忽略step；value必须满足value===min+n×step，否则浏览器静默修正；金额建议用“分”避免浮点误差。
step只对哪些type生效
只有 type="number"、type="range"、type="datetime-local" 这三类 input 才真正响应 step；写在 type="text"、type="email" 上，浏览器解析但完全忽略——spinner 按钮不出现、增减无效、校验不触发。常见错误是：<input type="text" step="0.01"> 看似想控精度，实则等同于没写。
value初始值必须和min、step对齐
step 不是独立开关，它和 min、value 构成数学约束：value 必须满足 value === min + n × step（n 为整数）。否则浏览器静默修正——你拖不动滑块、点 ↑ 却跳到非预期值、spinner 按钮失灵，八成卡在这儿。
- 错误示例：
<input type="number" min="1" step="0.3" value="1.0">→ Chrome 可能悄悄改成1.2或让控件失效 - 安全写法：
<input type="number" min="0.0" step="0.1" value="1.2">（确保1.2是0.0 + n×0.1的结果） - 动态改
step后，必须立刻重置value：input.value = (Math.round(parseFloat(input.value) / newStep) * newStep).toFixed(2)
金额类场景别碰浮点数
step="0.1" 点两次 ↑ 变成 0.30000000000000004 ——这不是 bug，是浮点数在二进制中无法精确表示 0.1 导致的底层误差。Chrome 旧版本甚至会静默把 step="0.1" 当作 step="1" 处理。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 可靠方案：金额统一用“分”：
min="100"、step="1"、value="199"表示 1.99 元 - 必须用小数时，显式写满位数：
min="0.00"、max="10.00"、step="0.01"，避免min="0"和step="0.01"混用 - 别自己算
parseFloat(val) + 0.1，改用原生input.stepUp(1)，它严格按当前step执行，不引入 JS 浮点误差
step="any"不是“不限制”，而是“退化为±1”
step="any" 并不放开所有限制，它只是禁用步长对齐逻辑：
立即学习“前端免费学习笔记（深入）”；
- 上下箭头、
stepUp()全部退化为整数增减：当前value="1.5"，点 ↑ 变成2.5，不是1.6 - 仍校验是否为合法数字（不能输
"abc"），但不再触发validity.stepMismatch - 手动输入
"1.23456789"完全允许，表单提交前也不报错——业务上必须靠 JS 或后端兜底 - 适合需要任意精度输入（如坐标、科学数据）且仍想保留原生 spinner 的场景，不是偷懒的“关闭校验”方案
真实麻烦从来不是写 step，而是用户粘贴、拖拽滚动条、第三方输入法——这些行为完全绕过 step 约束；它只管受控增减，不管自由输入。
