原生仅在chrome、edge及ios 16.4+/macos safari中点击触发系统时间选择器；firefox和旧版safari仅显示文本框。showpicker()兼容性差，需元素已挂载且非隐藏，建议settimeout调用；datetime-local在android更稳定，但需适配日期格式；全平台一致需js库兜底。
input type="time" 点击就弹出选择器，但只在部分浏览器生效
原生 <input type="time"> 在 Chrome、Edge 和 Safari（macOS/iOS 16.4+）里点一下输入框确实会触发系统级时间选择器；但在 Firefox 和旧版 Safari 中，它只是个可编辑文本框，不会弹窗。这不是你代码写错了，是浏览器实现不一致。
常见错误现象：click 事件里手动调用 showPicker() 报错 “not supported”，或者给 type="text" 加 onclick="openCustomPicker()" 结果点不动、失焦快、时间格式乱。
- 必须用
type="time"才可能触发原生弹窗，type="text"+ 自定义 JS 不会激活系统控件 - 移动端 iOS 16.4 之前不支持
showPicker()，Safari 桌面版至今不支持该方法 - 如果页面用了
inputmode="numeric"或pattern，可能干扰原生控件唤起
showPicker() 方法能主动唤起，但兼容性差且有前提条件
showPicker() 是新标准 API，调用它可以让 <input type="time"> 强制弹出选择器——但仅限已渲染、未禁用、且浏览器支持的环境。不是所有 time 输入框都能“喊出来”。
使用场景：需要在按钮点击、回车确认后才打开选择器，或绕过用户首次点击的“冷启动”延迟。
立即学习“前端免费学习笔记（深入）”；
- 必须确保元素已挂载 DOM，且
display !== "none"、visibility !== "hidden" - 不能在
focus()之前立刻调用showPicker()，建议加setTimeout(..., 0)或监听focusin - Firefox 全版本不支持，Safari 桌面版不支持，Android WebView 大多不支持
- 示例：
const el = document.querySelector('input[type="time"]');<br>el.focus();<br>setTimeout(() => el.showPicker(), 0);
用 type="datetime-local" 替代 time 可提升移动端兼容性
很多安卓机型对 type="datetime-local" 的支持比纯 time 更稳，尤其在 Chrome for Android 上，点一下大概率弹出带时分的滚轮选择器；而 type="time" 有时被降级为文本输入。
参数差异明显：datetime-local 要求值格式为 "YYYY-MM-DDTHH:MM"（无秒、无时区），服务端需适配解析逻辑；如果你只要选时间，得在提交前截掉日期部分，或用 JS 清除日期值。
- HTML 写法：
<input type="datetime-local" step="60">（step="60"表示分钟粒度） - 初始化值别写
value="14:30"，要写成value="2000-01-01T14:30"，否则无效 - iOS 上仍可能显示日期+时间双栏，但用户可忽略日期直接调小时分
真要全平台可控，就得放弃原生，用轻量 JS 库兜底
当项目要求“点就弹、所有设备一致、能定制样式”，原生方案已到极限。这时候选一个不依赖框架、体积小（flatpickr（设 enableTime: true, noCalendar: true）或 vanillajs-datepicker 的 time-only 模式。
容易踩的坑在于：引入后没关掉原生 type="time"，导致双控件重叠；或监听了 change 却漏掉 close 后的值同步；还有移动端 position: fixed 弹层被软键盘顶飞。
- 务必把原生 input 改成
type="text"并加readonly，防止光标进入和系统键盘干扰 - 初始化库时传入
appendTo: input.parentElement，避免脱离上下文定位失败 - 设置
time_24hr: true避免 AM/PM 切换带来的格式歧义
原生方案的边界很清晰：能接受 Firefox 不弹窗、能容忍 iOS 旧版本手输、服务端愿意接多种格式——那 type="time" 就够用。一旦其中一条不满足，就得切到 JS 控制流，没有中间态。
