<input type="time">仅支持时分秒，不包含日期，实现预约必须与<input type="date">配合使用，并通过拼接“YYYY-MM-DDTHH:mm:00Z”生成标准ISO时间字符串。
time 输入框默认不支持日期，只能选时间点
HTML 的 <input type="time"> 只处理小时和分钟（可带秒），不包含年月日。如果你要做“预约时间”，单靠它无法确定具体哪一天——用户可能今天选了 14:00，但实际想约下周三的 14:00。
常见错误是只放一个 <input type="time"> 就以为能完成预约，结果后端收到的时间片段根本没法入库或比对。
- 必须搭配
<input type="date">使用，两者值要同步采集 - 不要用
value硬写 “09:00” 这类固定值，除非业务强制默认时间 - 注意时区：用户本地选择的
14:00提交后，服务端解析成 ISO 时间时可能变成前一天或后一天（尤其跨夏令时）
获取 date + time 合并成完整 ISO 字符串的可靠写法
浏览器原生 <input type="date"> 和 <input type="time"> 返回的都是字符串，拼起来不能直接当 Date 构造参数用——比如 "2025-04-10" 和 "14:30" 拼成 "2025-04-1014:30" 会报错。
正确做法是手动补全分隔符和时区信息：
立即学习“前端免费学习笔记（深入）”；
const dateInput = document.querySelector('input[type="date"]');
const timeInput = document.querySelector('input[type="time"]');
<p>function getISODateTime() {
if (!dateInput.value || !timeInput.value) return null;
// 拼成 'YYYY-MM-DDTHH:mm' 格式，显式加 'Z' 表示 UTC，避免本地时区干扰
return <code>${dateInput.value}T${timeInput.value}:00Z</code>;
}</p><p>// 示例输出：'2025-04-10T14:30:00Z'</p>- 末尾加
:00Z是关键：补上秒和 UTC 标识，确保后端new Date(...)或DateTime.parse()能稳定解析 - 别依赖
toJSON()或toISOString()，因为输入框本身不返回Date对象 - 如果业务要求用用户本地时区（比如理发店排班），就去掉
Z，改用${dateInput.value}T${timeInput.value}，但务必在后端明确按本地时间处理
移动端 time 输入框兼容性差，得有降级方案
iOS Safari 直到 iOS 17.4 才支持 type="time" 的原生滚轮控件，更早版本会回退成文本框；Android 厂商定制系统也常禁用或修改行为。用户可能直接输 “下午2点半” 或 “2:30pm”，导致校验失败。
- 必加
pattern和title提示格式，例如：<input type="time" pattern="[0-9]{2}:[0-9]{2}" title="请用 24 小时制，如 14:30"> - 监听
input事件做实时格式清洗，把 “2:30 pm” 转成 “14:30”（可用moment().format('HH:mm')或轻量正则） - 真遇到不支持的 UA（如旧版 iOS），用 JS 库如
flatpickr或air-datepicker替代，但只加载一次，别无脑上
提交前必须校验时间是否早于当前时刻
预约场景下，用户不该能选今天已过去的时段（比如现在是 10:22，却选了 09:00）。仅靠前端校验不够，但至少拦住明显误操作。
注意：不能简单比字符串，因为 "10:00" > "09:00" 成立，但 "09:00" > "10:00" 在字符串比较里也成立（字典序）。
- 先合并成 ISO 字符串，再转
Date对象对比：new Date(getISODateTime()) > new Date() - 考虑服务器时间和用户本地时间偏差，建议预留 2 分钟缓冲（比如
new Date() + 2 * 60 * 1000） - 后端仍需二次校验，前端提示只是体验优化
真实预约逻辑远不止表单控件——比如时段冲突检测、服务人员空闲查询、节假日规则，这些都得在后端做。前端能做的，就是把用户意图准确、无歧义地传过去，少一点 undefined，少一点 "Invalid Date"。
