仅支持 HH:MM 格式，严格校验为24小时制两位小时加两位分钟；min/max 在iOS无效，step 在Safari和安卓厂商系统中不可靠；移动端需真机测试，z-index、overflow:hidden 和 inputmode 会破坏原生选择器；超出HH:mm需求应使用自定义组件。
input type="time" 能直接唤起系统级时间选择器，但只支持小时和分钟两级精度，秒字段无法交互、step 属性在多数浏览器中无效，且不兼容 IE 和旧版 Safari。
为什么 value 必须是 "HH:MM" 格式
浏览器对 value 属性校验极严：填 "2:30"、"2:30 PM" 或 new Date().toLocaleTimeString() 返回的任意带 AM/PM、空格、时区的字符串，都会导致输入框显示为空。只有严格符合 24 小时制、两位小时+两位分钟（如 "14:30"）才被接受。
- 正确赋值方式：
el.value = `${String(date.getHours()).padStart(2,'0')}:${String(date.getMinutes()).padStart(2,'0')}` - 错误示例：
el.value = new Date().toTimeString()→ 返回"14:30:22 GMT+0800"，前 5 位虽是"14:30"，但整个字符串非法 - 若需默认设为当前时间，推荐用
new Date().toISOString().slice(11,16)，它稳定输出"HH:MM"
min/max/step 在真实设备上表现如何
min 和 max 属性能生效，但仅限桌面端和部分 Android；iOS 系统选择器会忽略它们，仍允许用户滑动到范围外再手动提交。而 step 更不可靠：
-
step="900"（15 分钟）在 Chrome 桌面端有效，在 Safari 完全无响应 -
step="1"（秒级）Chrome 允许手动输入秒，但 iOS/Android 原生选择器根本不提供秒选项 - Android 厂商定制系统（如华为 EMUI、小米 MIUI）可能完全跳过
step解析 - 真正需要粒度控制，必须配合 JS 监听
change事件做二次校验或改用自定义组件
移动端真机测试绕不开的三个坑
模拟器和 DevTools 无法复现以下问题，必须在真实设备上验证：
- iOS Safari 在
position: fixed弹窗内使用type="time"，常因z-index层级被遮挡，导致点击无反应 - 父容器设置了
overflow: hidden，iOS 全屏时间选择器会被裁剪，变成半截黑屏 - 加了
inputmode="numeric"或其他inputmode值，会强制降级为纯文本框，原生选择器彻底失效
跨平台时间选择最稳定的底线是：接受它只管 HH:mm，不碰秒、不强求 step、不依赖 min/max 的 UI 限制，后端永远按 HH:mm 解析——所有超出这个范围的需求，都该交给自定义组件处理。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
