input 标签 min和max 属性在 Date 类型输入框中的范围限制逻辑

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）
• 若需统一行为，建议禁用原生校验（novalidate on form），改用 JS 全面控制

min/max 对日期选择器 UI 的影响有限

这些属性只约束可选日期范围，但不改变选择器控件本身的渲染逻辑。例如：当 min="2023-06-01"，用户仍可在日历视图中看到 5 月的日期格子（灰显不可点），但月份切换按钮（如“上一月”）依然存在，点击后可能显示空日历或全灰页面——这取决于浏览器实现，不是 bug，而是规范未定义 UI 行为。

• 不要指望 min/max 隐藏月份切换按钮或禁用导航，它们仅作用于“可选值集合”
• 若需更精细的 UI 控制（如禁用某个月份导航），必须用 JS 拦截 input 事件 + 自定义弹层，或引入第三方日期组件
• 移动端 Safari 的日期选择器对 min/max 支持较好，但早期 iOS 版本存在缓存旧值问题，建议每次设置后强制 input.value = "" 再重设

日期范围限制真正可靠的环节不在 HTML 属性，而在提交前的 JavaScript 校验和后端兜底；min/max 最多算一层弱提示，格式稍有偏差就完全失效。