safari（含桌面与ios）不支持原生，会降级为文本框；其value必须为严格24小时制hh:mm格式（如"09:30"），否则为空；min/max有效但校验时机因浏览器而异；跨平台需js检测后降级为select或轻量库。
time 输入框在 Chrome 和 Edge 中能用，但 Safari 不支持
HTML 的 <input type="time"> 在桌面端 Chrome、Edge 和 Firefox（部分版本）中表现稳定，Safari 桌面版至今（截至 macOS 14 / Safari 17）仍不支持原生时间选择器，会降级为普通文本框。这意味着用户必须手动输入 HH:MM 格式，且无校验、无弹出面板。移动端 iOS Safari 同样不支持，Android Chrome 则正常唤起滚轮时间选择器。
如果你的用户群包含大量 Mac/iOS 用户，仅靠原生 type="time" 无法保障体验一致性，需要准备降级方案。
value 必须是 24 小时制且带前导零，否则会被忽略
<input type="time"> 对 value 属性极其严格：只接受 HH:MM 格式（如 "09:30"），不接受 "9:30"、"09:30:00" 或任何空格/字母。传入非法值会导致控件显示为空，且 input.value 返回空字符串，而不是你传进去的原始字符串。
- 后端返回时间字段（如
"9:30"）需前端格式化：timeStr.padStart(5, '0')或用new Date().toTimeString().slice(0,5)（注意时区） - 不要试图写
value="9:30"直接塞进 HTML —— 浏览器会静默失败 - 设置默认值时，推荐用 JS 赋值：
el.value = '14:45'，比写死在 HTML 中更可控
min/max 限制有效，但 onChange 触发时机有差异
min 和 max 属性能正确禁用超出范围的时间选项（例如 min="08:00" max="17:30"），但在不同浏览器中触发验证的时机不同：Chrome 在用户点击“确定”后才校验并阻止提交；Firefox 可能在选择过程中就高亮错误；Safari 因无原生控件，完全不触发这些约束。
更关键的是，change 事件在时间选择器中只在用户确认选择后触发（比如点“完成”或失焦），而 input 事件在每次键盘输入或滚动时都触发——如果你要做实时校验或联动，优先监听 input，而非等 change。
示例：
input.addEventListener('input', () => {
if (input.checkValidity() === false) {
// 显示自定义提示，因为 :invalid 伪类在 Safari 中无效
}
});
真正跨平台可用的底线方案是「原生 time + 纯 JS fallback」
不要依赖 CSS 伪类（如 :valid）做兼容性判断，也不要指望 Modernizr.inputtypes.time 在新浏览器中依然可靠。最务实的做法是：先渲染 <input type="time">，再用 JS 检测是否生效：
- 检查
input.type === 'time'且input.supports('time')（不推荐，不可靠） - 更稳的方式：创建临时
input，设type='time'，再读取其type—— 如果返回'text'，说明不支持 - 一旦检测失败，动态替换为两个
<select></select>（小时/分钟）或一个轻量时间选择库（如 flatpickr 的 timeOnly 模式）
注意：所有 fallback 方案都要同步处理 min/max 和初始 value，否则逻辑割裂。时间格式化、时区、AM/PM 显示这些细节，原生控件不暴露接口，全得自己补。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
