date输入框的min/max属性仅支持YYYY-MM-DD格式字符串，动态设置需用setAttribute或格式化后赋值；其仅约束UI选择和提交校验，不阻止手动输入非法日期，且跨时区解析易出错。
date 输入框的 min 和 max 属性确实有效
浏览器原生 <input type="date"> 支持 min 和 max，但必须是符合 YYYY-MM-DD 格式的字符串（如 "2023-01-15"），不能用 Date 对象、时间戳或带时分秒的 ISO 字符串（如 "2023-01-15T08:00:00"）。否则属性会被忽略，UI 不生效，也不报错。
常见错误现象：
– 页面上日期选择器仍可选中超出范围的日期
– 控制台无报错，但表单校验（checkValidity()）返回 false，提交时浏览器弹出默认提示（如 “请输入在指定范围内的值”）
- 必须用
setAttribute('min', '2024-03-01')或直接写在 HTML 里，不能赋值input.min = new Date(...) - 若动态设置，建议先格式化日期：
input.min = formatDate(new Date(2024, 2, 1))（注意月份从 0 开始） - 空值或非法格式（如
"2024/03/01"）会导致该属性失效，等同于未设置
为什么设置了 min/max 还能手动输入非法日期？
原生 date 输入框的 min/max 仅约束 UI 选择器和表单提交校验，不阻止用户手动输入（例如粘贴、键盘输入）。这是浏览器标准行为，不是 bug。
使用场景：
– 用户通过日历控件选择时，会被限制在范围内
– 但若用户删除后手动输入 2022-01-01，浏览器不会实时拦截，只在调用 checkValidity() 或提交时才触发校验
- 需要实时拦截，得监听
input或change事件，手动校验并重置值 -
input.valueAsNumber在非法日期下返回NaN，可用作快速判断 - 注意 Safari 对手动输入的兼容性更弱——部分版本甚至不触发
change，建议加blur回退校验
min/max 与 JavaScript 日期对象转换的坑
JavaScript 的 Date 构造函数默认按本地时区解析，而 input.value 总是返回 UTC 零点的 YYYY-MM-DD 字符串。直接用 new Date(input.value) 可能在跨时区场景下偏移一天。
例如用户在东八区输入 "2024-03-01"：
– input.value 是 "2024-03-01"
– new Date("2024-03-01") 解析为 2024-02-29T16:00:00Z（即本地 3 月 1 日 00:00 → UTC 时间是 2 月 29 日 16:00）
- 安全做法：用
input.value.split('-')拆解年月日，再传给new Date(year, month - 1, day) - 设置
min前，推荐统一用toISOString().slice(0,10)生成字符串（前提是 Date 对象已按本地意图构造好） - 服务端永远以字符串接收，不要依赖前端传来的
Date对象做范围判断
移动端 date 输入框的兼容性现实
iOS Safari 和 Android Chrome 大多支持 min/max，但 Android 原生浏览器（尤其旧版）可能完全忽略。更隐蔽的问题是：某些安卓定制系统（如华为 EMUI）的日历控件不响应 min/max，但表单校验依然有效。
- 不要只靠视觉限制，后端必须做二次校验（这点比 PC 端更重要）
- 若需强一致性，可考虑降级为
type="text"+ 第三方 picker（如 flatpickr），但会失去原生体验和无障碍支持 - 测试时务必在真机上验证，模拟器常给出乐观结果
最易被忽略的一点：用户可能禁用 JavaScript，此时 min/max 仍生效（因为是 HTML 属性），但所有动态设置逻辑都失效——所以初始值一定要在 HTML 中写死或服务端渲染。
