单独使用无法约束日期，预约场景必须与 date 组合或改用 datetime-local（注意 safari 兼容性）；需手动拼接 iso 时间字符串并校验非空，动态限制时间段须 js 实现，移动端需 fallback 降级方案。
time 输入框默认不支持日期，必须搭配 date 一起用
单独用 <input type="time"> 只能选时分秒，无法约束“哪一天”，预约场景下几乎没用。真实业务中必须和 <input type="date"> 配合，或者直接改用 <input type="datetime-local">（但注意 Safari 旧版本不支持）。
常见错误是只放一个 time，用户选完时间后提交，后端发现缺少日期字段直接报错或默认当天——这不是前端漏传，是设计上就缺维度。
- 推荐组合：两个独立输入框，
date+time，语义清晰、兼容性好（IE10+ 都支持） - 如果追求单控件体验，用
datetime-local，但需 fallback：Safari 15.4 之前不支持，可检测document.createElement('input').type = 'datetime-local'是否被识别 - 别依赖
valueAsDate直接读取完整时间戳——time元素的valueAsDate返回的是当天的时分秒（日期部分固定为今天），容易引发时区错乱
获取完整时间戳得手动拼接 date 和 time 的值
date 输入框返回形如 "2024-06-15" 的字符串，time 返回 "14:30" 或 "14:30:00"，直接拼成 "2024-06-15T14:30" 才是合法 ISO 格式，能被 new Date() 正确解析。
容易踩的坑是拼错分隔符（比如写成空格或斜杠）、忽略时区（new Date("2024-06-15T14:30") 解析为本地时区，而 new Date("2024-06-15T14:30Z") 是 UTC）。
- 拼接模板：
dateInput.value + "T" + timeInput.value - 转时间戳前务必校验两个值都非空，否则
new Date("")返回Invalid Date - 服务端接收时建议统一要求 ISO 8601 字符串，避免前端用
.getTime()传毫秒数——时区处理逻辑容易前后端不一致
限制可选时间段要用 JavaScript 动态控制
HTML 原生的 min/max 对 time 只支持固定时间范围（如 min="09:00"），但预约常需“今天 9:00 后”或“工作日 9:00–17:00”，这种动态规则必须靠 JS 实现。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
典型做法是在 date 改变时重置 time 的 min/max 属性，并清空已选时间（避免用户选了无效组合）。
- 若选的是今天，
time.min应设为当前分钟向上取整到最近 30 分（如现在 14:22 → 设为"14:30"） - 若选的是明天及以后，
time.min可设为"09:00"，max设为"17:00" - 注意 Safari 对
time的min/max支持较弱，部分版本会忽略，需配合 JS 级校验提交时的值
移动端时间选择体验差，得准备降级方案
Android Chrome 的 time 输入框会唤起滚轮式时间选择器，但 iOS Safari（尤其 16 之前）只显示文本框，用户只能手输 14:30，极易格式错误。
这不是 bug，是 Safari 故意不实现原生时间控件，所以不能把体验建立在“用户会点开选择器”上。
- 必做：给
time输入框加pattern="[0-9]{2}:[0-9]{2}"和title="请输入 HH:MM 格式"，触发浏览器原生校验提示 - 进阶：监听
input事件，实时格式化用户输入（如自动补零、插入冒号） - 极端情况：当检测到 iOS Safari 且
type="time"不被支持时，回退到自定义下拉选择器（选项为["09:00", "09:30", "10:00", ...]）
真正麻烦的不是怎么写，而是不同系统对同一属性的解释差异太大——比如 step="1800"（30 分钟）在 Chrome 有效，在 Safari 就可能完全被忽略。实际项目里，往往要同时兼顾语义正确、降级可用、提交可靠三个目标，少一个都会导致用户卡在预约环节。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
