min/max仅在表单提交或checkValidity()时触发校验，不阻止键盘输入或粘贴；真正生效场景仅限微调按钮禁用和原生控件UI裁剪；需配合input事件、valueAsNumber及服务端双重校验确保安全。
min/max 不是拦截器，只是提交时的校验提示
设置 min="10" 和 max="100" 后，用户依然能键盘输入 999、粘贴 -5、甚至用开发者工具改 DOM 提交任意值。浏览器只在表单提交或调用 checkValidity() 时触发 validity.rangeUnderflow 或 validity.rangeOverflow，不阻止输入过程本身。
真正起作用的场景只有两个：上下箭头微调被禁用（超出范围时按钮灰掉）、原生日期/滑块控件 UI 被裁剪。数值型输入框的键盘输入完全不受控——这是标准行为，不是 bug。
-
min和max的值必须是合法数字字符串，比如"-3.14"、"42"；写成min="-3,14"（逗号）或min="abc"会导致属性静默失效 - 空字符串
min=""或缺失min属性，等价于min="-Infinity"，失去下限约束 - 未设
step时，type="number"默认step="1"，但用户仍可输入小数（如"10.5"），除非显式写step="1"或step="any"
input 事件里用 valueAsNumber 做实时裁剪
想让输入框“卡住”越界值，必须监听 input 事件，并优先使用 el.valueAsNumber 获取解析后的数值——它比 parseFloat(el.value) 更可靠，自动处理空值、非法字符返回 NaN，且与浏览器内部状态同步。
直接赋值 el.value = "10" 不会更新 valueAsNumber，而 el.valueAsNumber = 10 会同时修正两者，避免后续读取错乱。
立即学习“前端免费学习笔记（深入）”；
- 需判断
isNaN(el.valueAsNumber)，用户删空输入框时该值为NaN，不能直接比较 - 边界值要用
parseFloat(el.min)和parseFloat(el.max)动态读取，避免硬编码导致 HTML 和 JS 不一致 - 不要在
change事件里做裁剪，它不响应中间输入，只在失焦后触发，用户已看到越界值
step 配合 min 才能定义合法序列
step 不是独立精度控制，它的起点由 min 决定。例如 min="1" + step="2" 的合法值是 1, 3, 5...，不是 0, 2, 4...。若没设 min，起点默认为 0，可能导致第一个可选值不符合业务逻辑。
常见错误是只写 step="0.5" 却忽略 min，结果用户输入 0 后无法用箭头增减（因为 0 不在 min + n×step 序列中）。
-
step="any"允许任意小数，但某些旧版 Safari 支持不佳，生产环境建议显式写step="0.01" - 仅校验范围不够，还需按步长对齐：输入
4且min="1"step="2"时，应修正为5（向上取最近合法值），否则用户可能卡在非法中间态 - 移动端 iOS 键盘数字区不感知
step，用户仍可输入三位小数，JS 截断逻辑必须覆盖此场景
服务端永远要重校一遍范围
前端所有限制都可被绕过：禁用 JS、修改 DOM、用 curl 直接发请求。Python 后端收到 request.form.get("score") 后，必须重新解析为数字并比对阈值，不能信任任何前端传来的字符串。
推荐封装校验函数，明确抛出异常而非静默修正，便于日志追踪和前端统一提示：
def validate_range(value, min_val, max_val, name="数值"):
try:
num = float(value)
except (TypeError, ValueError):
raise OutOfRangeError(f"{name} 必须为数字")
if num < min_val or num > max_val:
raise OutOfRangeError(f"{name} 必须在 {min_val} 到 {max_val} 之间")
return num
最容易被忽略的是：HTML 中 min 和 max 是字符串，JS 里 input.min > input.max 是字典序比较（"10" > "2" 为 true），必须转数字再比；服务端同理，不能用字符串比较。
