Safari（含macOS和iOS）不支持原生<input type="time">时间选择器，仅降级为文本框；value必须为严格HH:mm:ss格式，否则清空；跨平台需JS库（如flatpickr）或自建UI兜底。
time 输入框在 Safari 上不显示时间选择器
这是最常被问到的问题：Chrome 和 Firefox 点击 <input type="time"> 会弹出原生时间选择器，但 Safari（包括 macOS 和 iOS）默认只提供文本输入，不触发任何时间 picker UI。
根本原因不是 bug，而是 Safari 官方尚未实现该控件的原生 UI 支持（截至 Safari 17.6 仍无变化）。它只解析并校验值格式，但不提供交互式选择器。
- 不要依赖
type="time"在 Safari 中有视觉反馈——它只是个带格式校验的文本框 - 若需跨浏览器一致体验，必须用 JS 时间选择库（如
flatpickr、vanillajs-datepicker）或自建 UI - 注意：iOS Safari 对
inputmode="numeric"+pattern="[0-9:]+"组合有一定软键盘优化，但无法替代 picker
value 值必须是 24 小时制且带秒（即使不显示）
<input type="time"> 的 value 属性只接受严格格式：HH:mm:ss，例如 "14:30:00"。写成 "2:30 PM" 或 "14:30" 都会导致值被清空或解析失败。
浏览器解析逻辑是：输入内容会被自动标准化为秒级完整格式；如果 DOM 中设了不合法的 value，控件会表现为空值（哪怕界面上看起来有内容）。
立即学习“前端免费学习笔记（深入）”；
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 设置初始值务必用
toISOString().substring(11, 19)或手动补零：例如String(hours).padStart(2,'0') + ':' + String(minutes).padStart(2,'0') + ':00' - 读取用户输入时，
input.value总是返回"HH:mm:ss"格式，哪怕用户只输了"9:5"（浏览器会自动补零并标准化） - 后端接收前别假设前端传的是
HH:mm—— 实际收到的几乎总是HH:mm:ss
min/max 校验在部分 Android 浏览器中失效
Android 系统 WebView（尤其旧版 Chrome for Android 或厂商定制浏览器）对 min/max 属性的支持不稳定。常见现象是：时间超出范围仍可提交，或 picker 滑块未禁用对应区间。
这不是 HTML 规范问题，而是底层 WebKit/Blink 实现差异。比如 Android 12 上某些 OEM 浏览器完全忽略 min="09:00:00"。
- 服务端必须做二次校验，不能信任前端
min/max - JS 层建议监听
change或input事件，手动比对new Date('1970-01-01T' + input.value)与边界时间戳 - 避免只靠属性控制业务逻辑，例如“仅允许预约未来 2 小时内的时间”——这种规则必须前后端双保险
无障碍支持差，屏幕阅读器识别率低
type="time" 在 VoiceOver、TalkBack 等主流读屏工具中普遍缺乏语义提示。用户听到的往往是“编辑文本”，而非“时间输入，小时分钟秒”，更不会播报当前值或可选范围。
WCAG 2.1 要求表单控件具备明确角色和标签，而原生 time 输入框在多数浏览器中未暴露足够 ARIA 信息。
- 必须显式添加
aria-label或关联<label>，例如<label for="meeting-time">会议开始时间</label><input id="meeting-time" type="time"> - 避免仅用 placeholder 当说明文字——它不被读屏器稳定读出，且失焦即消失
- 复杂场景（如带时区、AM/PM 切换）直接放弃原生控件，改用语义清晰的组合控件（
select+aria-live提示）
type="time" 当作“功能完备组件”来用。它本质是个轻量级格式化文本框，UI、校验、可访问性都得靠额外代码兜底——尤其当目标用户包含 iOS 用户或残障人士时。 
