min/max 对 type="number" 仅在表单提交或 checkValidity() 时校验，不实时拦截；需配合 step 处理小数，value 始终为字符串须转数字比较；type="date" 要求严格 YYYY-MM-DD 格式；range 滑块需监听 input 事件截断值；服务端校验不可省略。
min/max 对 type="number" 的限制怎么起作用
它只在表单提交或调用 checkValidity() 时触发校验，不是实时拦截。用户仍能粘贴 -5、输入 1000 或清空后提交——除非你加了 required。
-
min和max必须是字符串，比如min="18"，写成min=18（没引号）或 React 里min={18}会失效 - 小数必须配
step：想支持min="0.5" max="9.9"，就得写step="0.1"；不设step时默认为1，输3.5可能被自动舍入或校验失败 -
input.value永远是字符串，比较前必须转数字：parseFloat(input.value) ，直接用"10" 会出错 - 清空输入框时
value是空字符串，valueAsNumber是NaN，此时范围校验不触发——得先判断非空再比
type="date" 的 min/max 为什么经常不生效
因为格式错一丁点就静默失效：浏览器只认严格 YYYY-MM-DD，比如 min="2024-01-01" ✅，而 min="2024/01/01"、min="2024-1-1"、min="2024-01-01T00:00" 全部 ❌。
- 动态设置时别用
new Date().toISOString().split('T')[0]：UTC 时间可能导致本地日期偏差一天 - 稳妥做法是手动补零：
`${d.getFullYear()}-${String(d.getMonth() + 1).padStart(2, '0')}-${String(d.getDate()).padStart(2, '0')}` - Safari 直到 v17+ 才在日历弹窗中禁用超限日期，旧版本只在提交时校验，甚至完全忽略
min/max - 用户仍可键盘输入任意合法格式日期（如
1900-01-01），控件不阻止——这是设计行为，不是 bug
如何让 range 滑块真正卡死在 min/max 范围内
只写 不够，滑块初始值可能越界，拖动时也可能短暂超出——必须监听 input 事件主动截断。
- 显式设置
value，且确保落在[min, max]内；否则浏览器会自动修正，但行为不一致 - 用
input.valueAsNumber读值（返回数字或NaN），比parseFloat(input.value)更准，尤其对小数 - 别依赖
change：它只在松手后触发，拖动过程中无法同步显示；用input事件才能实时响应 - 移动端要注意：iOS 默认滑块高度太小，加
height: 40px防误触；某些安卓 WebView 会忽略step="0.1"，降级为整数步进再 JS 映射
为什么服务端校验不可跳过
因为所有前端限制都能被绕过：禁用 JS、改 DOM、发裸 HTTP 请求、用 Postman 直接 POST —— 浏览器的 min/max 就是 UI 提示层，不是安全边界。
- 用户粘贴
abc或999999后未失焦就点提交，Chrome 可能来不及校验 - JS 动态赋值
input.value = "-10"不触发校验，得手动调input.reportValidity() - 业务关键字段（如年龄、金额、日期）必须在后端用相同逻辑二次判断，比如 Python 里
if not (18 - 别信“用户不会乱来”——真实日志里满是绕过前端的异常请求，只是多数人没查
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
