需用 JavaScript 监听 change 事件实时校验日期依赖关系，先判空再解析为 Date 比较时间戳，用 setCustomValidity 和 reportValidity 实现原生反馈，并同步清空过期错误；Element UI 等框架推荐用 disabledDate 从源头禁用非法选项；前后端均需校验且统一使用 ISO 本地日期字符串防时区偏差。
用 JavaScript 监听 change 事件做实时比对
HTML 原生的 min 和 max 属性只能设固定边界，无法表达“结束日期必须 ≥ 开始日期”这种动态依赖关系。必须靠 JS 实时读取两个 <input type="date"> 的值，转成 Date 对象后比较时间戳。
常见错误现象：直接写 new Date(input.value) ，但当任一输入为空时，<code>new Date("") 返回 Invalid Date，后续比较结果为 false 或 NaN，校验失效。
- 先检查
input.value是否非空，空值直接跳过校验逻辑 - 用
new Date(dateString)解析（现代浏览器支持"2026-09-21"格式，无需正则替换-） - 用
.getTime()获取毫秒数再比较，避免Date对象直接比较的隐式转换陷阱 - 若发现
end ，调用 <code>end.setCustomValidity("结束日期不能早于开始日期")，并触发end.reportValidity()立即反馈
用 setCustomValidity 配合表单原生提交拦截
浏览器原生表单校验只在 submit 时自动触发，但你可以提前用 setCustomValidity() 注入错误状态，让 form.checkValidity() 返回 false，从而阻止提交。
关键点在于：错误信息必须绑定到具体字段，且清空逻辑要同步。比如用户改了开始日期，结束日期的错误提示可能已过期，这时要主动调用 end.setCustomValidity("")。
立即学习“前端免费学习笔记（深入）”；
- 监听
start的change事件：只要它变了，就清空end的自定义错误（end.setCustomValidity("")） - 监听
end的change事件：解析后若end ，设置错误；否则清空 - 不要在
submit事件里重复校验——原生机制已覆盖，重复写反而容易漏掉reportValidity()调用
Element UI 等框架中用 disabledDate 控制可选范围
如果你用的是 Element UI，el-date-picker 的 picker-options.disabledDate 是更顺滑的方案：它不靠事后报错，而是从源头禁用非法选项。
注意两个方向都要配：开始日期选择器要禁用晚于当前结束日期的选项，结束日期选择器要禁用早于当前开始日期的选项。两者依赖对方的值，所以必须用函数返回布尔值。
pickerStartOptions.disabledDate = (time) => this.form.end_time && time.getTime() > new Date(this.form.end_time + ' 23:59:59').getTime()pickerEndOptions.disabledDate = (time) => this.form.start_time && time.getTime()- 务必确保
this.form.start_time和this.form.end_time是响应式数据，否则函数内读不到最新值
后端也要校验，前端只是第一道防线
JS 校验能提升体验，但完全可被绕过。真实系统中，后端收到 start 和 end 参数后，仍需做一次服务端比对，失败则返回 400 并附带错误字段信息。
容易被忽略的是时区问题：前端 new Date("2026-09-21") 在东八区生成的是 2026-09-21T00:00:00+08:00，而 Java 的 LocalDate.parse() 默认按系统时区解析，若服务器在 UTC 时区，同字符串会变成 2026-09-20 —— 导致前后端日期差一天。
- 前后端统一用 ISO 本地日期字符串（
"2026-09-21"）交互，不带时间部分 - 后端校验逻辑应基于
LocalDate或等价类型，避免用Instant或Date引入时区偏移 - 若业务允许跨日请假，需明确“天数”是否含首尾、是否剔除节假日——这些规则前端可预计算，但最终以服务端为准
