step属性无法限制抽奖概率，仅控制数值输入步长；概率需非负、可为小数、总和为1，须用JS实时校验与归一化处理。
step 属性不能限制抽奖概率输入——它只控制表单控件的数值增量步长，和“概率”这种业务逻辑完全无关。
为什么 step 对抽奖概率没用
step 仅在 <input type="number"> 或 type="range" 中生效，作用是限定用户能输入/拖动的值必须是 min + n × step 的形式。比如 min="0" max="1" step="0.1" 允许 0、0.1、0.2…0.9、1，但不阻止用户手动输入 0.15（除非加 oninput 拦截），更不会校验“所有概率之和是否为 1”这类业务规则。
抽奖概率的核心约束是语义性的：多个选项的概率需非负、可为小数、总和应为 1（或 100%）。这些靠 step 根本覆盖不到。
真正该用的方案：组合验证 + 实时计算
要让抽奖概率输入靠谱，得靠 JS 主动控制和校验，而不是依赖 HTML 原生属性。常见做法包括：
立即学习“前端免费学习笔记（深入）”；
- 用
<input type="number" min="0" max="1" step="0.01">提供基础引导，但不依赖它做逻辑判断 - 监听
input或blur事件，对每个值做Math.max(0, Math.min(1, parseFloat(val) || 0))截断处理 - 每次修改后立刻计算总和，用
Number.EPSILON级别比较（避免0.1 + 0.2 !== 0.3问题） - 若总和超限，自动按比例缩放其余项（或冻结最后一个输入框并提示）
容易被忽略的坑：浮点精度与边界归一化
直接用 parseFloat + toFixed(2) 再转回数字会引入隐式四舍五入误差，导致总和飘移。例如四个 0.25 输入后变成 0.25 + 0.25 + 0.25 + 0.249 = 0.999。
更稳妥的做法是：内部始终用整数存储（如千分比），显示时再除以 1000；或者在归一化时采用「保留最大误差项」策略——把差额加到最大概率项上，而非均摊。
另外，step="0.01" 在某些浏览器中对 valueAsNumber 读取仍有兼容差异，建议统一用 parseFloat(input.value) + 显式范围检查。
概率输入的本质是数据一致性维护，不是表单格式控制。别让 step 给你虚假安全感。
