原生 date/time 输入框需用 change 事件动态更新 min 属性实现联动：start.value 非空时设 end.min = start.value，为空时设 end.min = ""；time 类型仅支持同天约束，跨天需换方案；禁用 input 事件和 setCustomValidity() 替代 min，推荐封装自定义 datetime-range 元素统一处理边界。
用 min 和 max 属性做基础联动，但必须配 JS 动态更新
原生 <input type="date"> 不会自动让“结束日期不能早于开始日期”，min 和 max 只是静态属性，设一次就固定了。用户选完起始日期后，结束日期框的 min 必须立刻更新为对应值，否则无效。
关键点：
-
start.addEventListener("change", () => { end.min = start.value; })是最简路径，但要注意start.value是"YYYY-MM-DD"格式字符串，不能直接传new Date()或时间戳 - 如果起始日期清空（
start.value === ""），必须手动设end.min = ""，否则残留的min会继续限制选择 - 不要用
input事件监听——用户还没输完（比如只打了"2026-"）就会触发，导致start.value为空或非法，end.min被设成空字符串或乱值
type="time" 联动要小心时分格式和同天限制
<input type="time"> 的 min 只接受 "HH:MM" 字符串，且它天然不跨天。这意味着：如果开始时间是 "23:59"，结束时间 min 设为 "23:59" 后，"00:00"（次日）会被禁用，因为字符串比较中 "00:00" 为真。
所以这个方案只适用于「同一天内」的时间段约束。如果你需要跨天（比如夜班从 22:00 到次日 06:00），原生 type="time" 就不适合，得换方案（比如用 datetime-local 或自定义控件）。
实操建议：
- 监听
change，不是input；start.value为空时，立刻清除end.min - 如果
end.value已存在但小于start.value，可选地重置它：end.value = start.value，避免用户提交无效值 - 不要依赖
valueAsNumber或valueAsDate读取time输入——Firefox 不支持，统一用.value字符串比较更稳
为什么别急着用 setCustomValidity() 替代 min
setCustomValidity() 是提交时的兜底校验，不是 UI 级联动。它不会禁用选项、不会灰掉早于起始时间的日期，用户照样能点、能输、能粘贴无效值，直到点提交才弹错——体验割裂，尤其在移动端容易误操作。
它适合的场景是：后端返回冲突（比如该时间段已被预订），而前端无法预知。这时候再用 setCustomValidity() + reportValidity() 提示更合理。
若硬要用，注意：
- 每次
start变化后，必须调用end.checkValidity()，否则错误状态不会刷新，reportValidity()也不生效 - iOS Safari 对
setCustomValidity()的弹窗样式支持弱，文字可能被截断或无图标，用户容易忽略 - 和
min混用时，浏览器优先响应min约束，setCustomValidity()不会覆盖它
真正要复用？别拼原生标签，封装成自定义元素
两个 date + 两个 time 手动联动写三遍，维护成本高。原生控件本身不提供“日期范围”语义，datetime-local 又在 Safari/iOS 上长期不支持（退化成文本框），纯靠 HTML 写不出可靠组件。
轻量可行的做法是封装一个 <datetime-range></datetime-range> 自定义元素，内部管理四个输入框 + 联动逻辑。重点不是 DOM 结构，而是把以下行为固化：
- 起始
date更新 → 结束date.min同步 - 起始
date和time都有值，且起止日期相等 → 结束time.min同步 - 任意字段
change后，校验整体有效性，暴露isValid属性和invalid事件 - 对外只暴露
startDate/endDategetter，隐藏底层输入框细节
复杂点不在 JS 逻辑，而在边界处理：比如 2 月 30 日、闰年、时区切换、用户粘贴非法字符串。这些一旦漏掉，表单就不可靠——别指望用户自己发现。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
