date input 的 min/max 按 YYYY-MM-DD 字符串字典序比较，格式错误（如缺零）则属性失效；浏览器行为不一，Chrome/Edge 失焦自动修正，Firefox 仅标记无效；必须用 Date 对象校验并依赖 JS 和后端兜底。
date 类型 input 的 min 和 max 是按字符串字典序比较的
浏览器对 <input type="date"> 的 min/max 校验，底层不解析为日期对象，而是直接按 YYYY-MM-DD 格式字符串做字典序（lexicographic）比对。这意味着只要格式合法、长度固定（10 字符），就能参与比较；但一旦格式错（比如 "2023-1-5" 缺零），min/max 会失效——浏览器直接忽略该属性，不报错也不限制。
常见错误现象：
• 输入框可选到 min 之前或 max 之后的日期
• 控制台无报错，开发者误以为逻辑生效了
• 表单提交时浏览器原生校验未触发（checkValidity() 返回 true）
-
min和max值必须严格为"YYYY-MM-DD"格式（如"2023-01-01"），不能是"2023/01/01"或"01/01/2023" - 服务端返回的日期若为
"2023-1-5"，需前端补零再赋给min属性，否则无效 - JavaScript 中用
toISOString().split("T")[0]或new Date().toJSON().slice(0,10)可安全生成合规字符串
用户手动输入超出 min/max 范围时，浏览器行为不一致
Chrome 和 Edge 会在失焦（blur）时自动修正为边界值（如输 "2020-01-01" 但 min="2023-01-01"，会跳变为 "2023-01-01"）；Firefox 则保留非法值并标记为无效（input.validity.rangeUnderflow === true），且不自动修正。这种差异直接影响表单提交拦截逻辑。
- 不能依赖浏览器自动修正来保证数据合规，必须在
submit事件中手动校验input.value是否落在[input.min, input.max]内 - 校验时需将
min/max和value全部转为Date对象再比较，避免字符串比较陷阱（如"2023-10-01" < "2023-9-01"为true） - 若需统一行为，建议禁用原生校验（
novalidateon form），改用 JS 全面控制
min/max 对日期选择器 UI 的影响有限
这些属性只约束可选日期范围，但不改变选择器控件本身的渲染逻辑。例如：当 min="2023-06-01"，用户仍可在日历视图中看到 5 月的日期格子（灰显不可点），但月份切换按钮（如“上一月”）依然存在，点击后可能显示空日历或全灰页面——这取决于浏览器实现，不是 bug，而是规范未定义 UI 行为。
- 不要指望
min/max隐藏月份切换按钮或禁用导航，它们仅作用于“可选值集合” - 若需更精细的 UI 控制（如禁用某个月份导航），必须用 JS 拦截
input事件 + 自定义弹层，或引入第三方日期组件 - 移动端 Safari 的日期选择器对
min/max支持较好，但早期 iOS 版本存在缓存旧值问题，建议每次设置后强制input.value = ""再重设
min/max 最多算一层弱提示，格式稍有偏差就完全失效。 
