type="number"是前提，min/max仅对number类型生效；text类型下属性被忽略；需用input事件实时校验数值范围与step对齐，并强制服务端二次校验。
type="number" 是前提，type="text" 加 min/max 完全无效
浏览器只对语义化类型解析 min 和 max 属性。type="text" 时这两个属性被彻底忽略——控制台执行 el.min 会返回空字符串，连 DOM 属性都读不到。常见错误写法：<input type="text" min="0" max="100">，用户输入 999 不拦截、不报错、增减按钮也不灰显。修复只需改 type：必须是 <input type="number" min="0" max="100">，且值必须用引号包裹（"0"，不是 0）。
input 事件才是实时拦截的关键，别用 change 或 keydown
min/max 本身不阻止键盘输入或粘贴，只参与提交校验。真正能覆盖中间过程的只有 input 事件。用 change 会等到失焦才触发，用户早输完非法值了；在 keydown 里 preventDefault() 又会干掉退格、小数点、方向键等合法操作。
核心逻辑是：监听 input → 用 parseFloat(el.value) 转数值 → 对比 parseFloat(el.min) 和 parseFloat(el.max) → 超限时直接赋值边界值。必须处理空值：parseFloat("") 返回 NaN，不加 isNaN(val) 判断会导致后续比较恒为 false。
step 不只是“步长”，它决定合法值序列的起点和间隔
step 和 min 是绑定关系。例如 min="1" + step="2"，合法值是 1, 3, 5...，而不是 0, 2, 4...。用户输入 4，浏览器可能允许，但 Express Validator 等后端校验库会拒绝——因为 4 不满足 1 + n×2 的形式。
立即学习“前端免费学习笔记（深入）”；
- 业务要求整数范围，就写
step="1" - 要支持一位小数，显式写
step="0.1"，别依赖默认 -
step="any"会让增减按钮失效，且失去所有步长约束，慎用 - 未设
min时，step默认从0开始，容易导致第一档值不符合业务预期
服务端二次校验不可省，前端限制只是体验优化
所有前端限制都可被绕过：开发者工具直接改 DOM、禁用 JS、curl 提交、甚至手写 HTTP 请求。仅靠 min/max 或 JS 截断，无法保障数据安全。后端必须独立解析并校验数值范围、类型、步长对齐（如是否为 min + n×step），不能信任任何客户端传来的值。
最容易被忽略的一点：当 step 与 min 不匹配时（比如 min="0.5" 却没配 step），某些框架或校验库会在解析阶段就抛出格式错误，而非等到业务逻辑层——这说明步长约束已深入到数据解析环节，不是可有可无的装饰。
