原生 <input type="time"> 可直接唤起系统级时间选择器，轻量且语义化，但不支持自定义格式、步进限制，且不兼容 IE 和部分老版 Safari；value 必须为 "HH:MM" 格式，需注意时区与 iOS 兼容性问题。
原生 <input type="time"> 就能直接唤起系统级时间选择器，不需要 JS、不依赖第三方库，移动端体验好，PC 端也基本可用——但得注意它不支持自定义格式、不能限制步进（比如只允许 15 分钟一档）、也不兼容 IE 和部分老版本 Safari。
用 <input type="time"> 快速启用系统时间选择器
这是最轻量、最符合语义的做法。浏览器会根据平台自动调起原生控件：iOS 上是滚轮式时间选择器，Android 是数字键盘或时钟视图，桌面端则显示为带上下箭头的文本框。
-
value必须是"HH:MM"格式（24 小时制），例如"14:30"；填"2:30"或"2:30 PM"会失效 - 加
required属性可触发表单校验，但用户清空后再次点击不会自动恢复默认值 - 不支持
step属性在所有浏览器生效（Chrome 支持step="900"表示 15 分钟，Safari 忽略） - PC 端无法阻止用户手动输入非法时间（如
"25:99"），需配合 JS 监听input或change做二次校验
为什么 new Date().toTimeString() 不适合做时间弹窗值回填
因为 toTimeString() 返回的是类似 "14:30:22 GMT+0800 (CST)" 的完整字符串，而 <input type="time"> 只认前 5 位 "HH:MM"。直接赋值会导致控件显示为空或异常。
- 正确做法是用
date.toISOString().slice(11,16)（取 ISO 字符串的小时分钟段） - 或者手动拼接：
${String(date.getHours()).padStart(2,'0')}:${String(date.getMinutes()).padStart(2,'0')} - 注意时区：
getHours()返回本地时区时间，如果业务要求统一 UTC 时间，得用getUTCHours()
遇到 iOS Safari 不触发时间选择器？检查这三点
iOS 16.4+ 修复了大部分问题，但仍有几个常见卡点：
立即学习“前端免费学习笔记（深入）”；
- 父容器设置了
overflow: hidden，会裁剪弹出层——时间选择器在 iOS 是全屏模态，但某些 Webview 会受父级样式干扰 - 元素被
position: fixed包裹且z-index过低，导致选择器被遮挡（尤其嵌套在弹窗/Modal 内时） - 用了
inputmode="numeric"或其他 inputmode 属性，会覆盖原生 time 类型行为，直接禁用即可
需要精确到秒或自定义步进？别硬改 type="time"
原生控件对 step 的支持非常碎片化：step="1"（秒级）在 Chrome 有效，在 Safari 完全无效；step="300"（5 分钟）在部分 Android 厂商定制系统里也不起作用。
- 真要控制粒度，建议用
<input type="text">+ 自研时间选择器（如 flatpickr、@vueuse/core 的useTimeAgo配合自定义 UI） - 若仅需秒级显示，可用两个
<input type="number">分别控制时、分、秒，再用 JS 合并校验 - 注意：任何非原生方案都会失去系统级无障碍支持（VoiceOver / TalkBack 对原生 time 控件有专门优化）
真正容易被忽略的不是怎么写，而是什么时候不该写——比如后台管理页用桌面浏览器居多，强行上原生 time 输入体验反而不如下拉选择；而预约类 H5 页面，哪怕多写几行兼容逻辑，也值得换一个手指点一下就能选中的原生体验。
