后端校验不能依赖前端 step 值，因其不随请求发送；应统一用整数单位（如金额存“分”）校验，避免浮点精度问题，并采用区间+小数位数约束。
后端校验不能依赖前端 step 值
浏览器的 step 属性只影响前端交互和表单提交时的原生校验，它不会发送到后端，也不参与任何服务端逻辑。后端永远收不到这个属性——你看到的 step="0.01" 在 HTTP 请求体里根本不存在。
常见错误是后端硬编码校验逻辑（比如用 value % 0.01 !== 0 判定金额非法），结果因浮点精度问题误拒合法值（如 99.99 在 JS 中可能存为 99.98999999999999，后端用 float 计算也会出偏差）。
- 后端应统一用整数单位做校验：金额存“分”，步长换算为
1；温度存“十分之一度”，步长即1 - 避免在后端直接复现前端
step的浮点计算逻辑，改用区间+精度约束（例如：允许两位小数、且数值 ∈ [min, max]） - 若业务需动态步长（如“step_mode="tiered" 字段），不能靠解析 HTML 推断
前后端步长语义必须对齐，不能只看数值
step="0.1" 在前端表示“从 min 开始，每次加 0.1”，但后端若只检查 value * 10 是否为整数，就忽略了 min 的偏移作用。比如 min="1.5" step="0.2" 的合法值是 1.5, 1.7, 1.9...，而非所有一位小数。
后端验证公式应严格对应浏览器行为：(value - min) % step ≈ 0（用整数倍判断，或转成字符串截取小数位比对）。
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 推荐做法：后端只校验数值范围（
min ≤ value ≤ max）和小数位数（如最多 2 位），不复现 step 模运算 - 若必须校验步长，把
min、max、step作为 API 参数传入，后端用整数运算重算（如全部 ×100 后取模） - 特别注意
step="any"：它代表“不限步长”，后端不能因此跳过精度检查——仍要按业务要求限制小数位（如价格字段始终只接受 2 位）
动态 step 场景下，后端必须收到明确配置
前端用 JavaScript 动态改 input.step 或切换不同 step 规则时，这些变更完全不会自动同步到后端。用户提交时，后端拿到的只是最终 value 字符串。
比如一个滑块在“基础模式”下 step="1"，在“精细模式”下 step="0.1"，仅靠 input 值无法反推用户当时处于哪种模式。
- 必须额外提交上下文字段，例如：
{"value": 12.3, "step_mode": "precise", "unit": "celsius"} - 后端据此决定校验粒度：若
step_mode === "precise"，则要求小数位 ≤ 1；若为"coarse"，则只接受整数 - 不要试图在后端解析 HTML 模板或 JS 逻辑来还原 step 行为——它不可靠、难维护、且存在安全风险
最容易被忽略的一点：step 的浮点陷阱在后端会放大
前端输入 0.3，浏览器内部可能已存储为 0.30000000000000004；若后端用 float 类型接收并直接参与模运算，误差会叠加。更糟的是，某些语言（如 PHP）的 fmod() 对浮点数处理极不稳定。
真正健壮的做法是绕过浮点计算：
- 接收时强制转字符串，用正则提取小数部分长度（
/.(\d+)$/.exec(val)） - 或统一转为整数：金额 ×100、温度 ×10，全部用整型运算
- 校验失败时返回明确错误码（如
"STEP_MISMATCH"）和可读提示（“请输入 0.1 的整数倍”），而不是让前端猜后端逻辑
