safari 不支持 ，需用 js 库 fallback；value 必须为 hh:mm 格式（如 "09:30"）；min/max 仅字符串比较，不支持跨日；值无时区信息，业务需额外处理时区或改用 datetime-local。
time 输入框在 Chrome 和 Edge 中能用，但 Safari 不支持
HTML 的 <input type="time"> 在桌面端 Chrome、Edge、Firefox（部分版本）中可直接唤起原生时间选择器，但在 macOS/iOS Safari 中始终显示为普通文本框，用户必须手动输入 HH:MM 格式。这不是 bug，而是 Safari 官方未实现该表单控件——截至 iOS 17 和 macOS Sonoma 仍无计划支持。
如果你的用户群包含大量苹果设备用户，仅靠 type="time" 无法保证体验一致性。实际项目中建议搭配 JavaScript 时间选择库（如 flatpickr）或自行 fallback 到自定义下拉/滑动组件。
value 必须是 24 小时制且带前导零，否则会被浏览器忽略
<input type="time" value="9:30"> 在多数浏览器中不会生效，因为规范要求 value 必须严格匹配 HH:MM 格式（例如 "09:30"）。不带前导零、多出秒数（如 "09:30:00"）、使用 AM/PM 都会导致初始值为空或解析失败。
- 正确写法：
value="14:45"、value="00:00" - 错误写法：
value="2:45"、value="14:45:30"、value="2:45 PM" - JavaScript 设置时也需格式化：
input.value = new Date().toTimeString().slice(0,5)不可靠，推荐用String(padStart(2))手动补零
min/max 属性只校验时间值，不处理跨日逻辑
min 和 max 可限制可选范围，比如 min="09:00" max="17:30"，但它们仅做字符串比较（按字典序），不理解“时间先后”。这意味着 min="23:00" max="01:00" 不会允许 00:30 —— 因为 "01:00" 字符串比较结果为 true，整个范围被视为空集，浏览器通常禁用全部选项或清空输入。
若需跨日时段（如夜班 22:00–06:00），无法靠原生属性实现，必须用 JS 拦截输入 + 自定义验证逻辑。
获取和提交的值永远不含时区，且默认为本地时间
无论用户在哪个时区，input.value 返回的都是纯时间字符串（如 "15:20"），没有时区标识；表单提交时也只发这个字符串。后端收到后无法区分这是 UTC 还是东八区时间——它只是“当天的这个时刻”。
如果业务需要与时区绑定（例如预约系统要存 UTC 时间戳），不能依赖前端 type="time" 单独工作：
- 需额外提供时区选择控件（
<select></select>或<input type="hidden">存Intl.DateTimeFormat().resolvedOptions().timeZone） - 或改用
datetime-local（同样有 Safari 兼容问题，且值含日期） - 更稳妥的做法：用
<input type="text">配合 JS 时间库（如 dayjs）解析并转成 ISO 时间戳再提交
原生 time 输入框轻量、语义清晰，但它的能力边界非常明确：只适合纯本地时间展示与简单录入，一旦涉及跨时区、跨日、强校验或兼容性要求，就得立刻引入补充方案。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
