HTML input[type="date"]的min属性必须设为静态ISO格式日期字符串（如"2024-06-15"），需用JavaScript在DOM加载后动态设置：document.getElementById('date-input').min = new Date().toISOString().split('T')[0]；min仅前端校验，后端必须重复验证。
HTML input[type="date"] 的 min 属性必须设为今天或之后的日期字符串
浏览器原生日期控件不支持“动态禁止过去日期”的自动更新，min 值必须是静态的 ISO 格式日期字符串（如 "2024-06-15"），不能写成 min="today" 或 min="new Date()" 这类无效写法。
常见错误是直接在 HTML 中硬编码一个固定日期，导致第二天就失效。正确做法是在页面加载时用 JavaScript 动态生成当天日期并赋值：
document.getElementById('date-input').min = new Date().toISOString().split('T')[0];
-
toISOString()返回形如"2024-06-15T08:30:00.000Z"的字符串，取split('T')[0]得到"2024-06-15" - 必须在 DOM 加载完成后执行，否则
getElementById可能返回null - 不建议用
toLocaleDateString()，它格式不统一（如可能输出"15/06/2024"），min只接受YYYY-MM-DD
用户仍可能绕过 min 限制：手动输入、开发者工具修改、旧版 Safari
min 是纯前端校验，仅影响表单提交前的浏览器默认提示（如 Chrome 会禁用过去日期格子、Safari 显示警告），但无法阻止用户通过以下方式提交非法值：
- 手动在输入框中键入过去日期（例如删掉年份改成
"2020-01-01"） - 用浏览器开发者工具直接修改
min属性或value - Safari 15.4 及更早版本对
min支持不完整，可能完全忽略
因此，后端必须重复校验日期是否为未来时间，前端只做体验优化，不能替代服务端验证。
立即学习“前端免费学习笔记（深入）”；
需要实时反馈？监听 input 和 change 事件做即时判断
仅靠 min 无法触发自定义提示（比如红色边框、下方文字提醒）。要实现用户选完立刻反馈，需监听事件并比对时间戳：
const input = document.getElementById('date-input');<br>input.addEventListener('input', () => {<br> const selected = new Date(input.value);<br> const today = new Date();<br> today.setHours(0, 0, 0, 0); // 清除时分秒，避免跨天误判<br> if (selected < today) {<br> input.setCustomValidity('请选择今天或之后的日期');<br> } else {<br> input.setCustomValidity('');<br> }<br>});
- 用
input事件而非change，确保用户手动输入时也能响应 -
setCustomValidity触发浏览器原生验证气泡，无需额外 DOM 操作 - 注意清除时分秒——否则
new Date("2024-06-15")默认是当日凌晨，而new Date()包含当前时分秒，可能导致刚过午夜就判定失败
移动端兼容性差异大，别依赖视觉禁用效果
Android Chrome 会灰掉过去日期格子，iOS Safari 却只在点击后弹出警告，且不灰显；部分国产安卓浏览器甚至完全忽略 min。这意味着：
- 不能假设用户“看不到”过去日期——他们可能根本没注意到灰显，或压根没看到提示
- 不要用 CSS 选择器如
input::before或[disabled]做样式强化，原生控件不支持这些伪元素 - 如果业务强依赖日期有效性（如预约系统），建议改用带日历面板的 JS 库（如 flatpickr），它可统一控制禁用逻辑和样式
真正容易被忽略的是：日期比较必须基于 UTC 时间戳，而不是字符串字典序。比如 "2024-01-01" > "2023-12-31" 虽然成立，但一旦涉及时区（如用户在东京、服务器在伦敦），new Date(value).getTime() 才是可靠依据。
