原生 input type="time" 兼容性差且行为不可控，应检测支持性并降级为受控文本输入+inputmode="numeric"+实时格式化。
input type="time" 点击无反应或无法输入文字
绝大多数情况不是控件坏了，而是它根本没被浏览器当作可编辑的 time 控件来渲染——type="time" 在不支持的环境（如旧版 Safari、部分 WebView、禁用 JS 的页面）会自动降级为 type="text"，但样式和交互逻辑没同步调整，导致光标闪烁却输不进内容。
检查方法很简单：右键审查元素，看 input 标签上是否还保留 type="time"；如果 DOM 里是 type="time"，但行为像普通文本框，说明当前浏览器不支持该类型，必须降级处理。
- iOS Safari 16.6 之前不支持
type="time"，仅显示文本框，且常因inputmode缺失导致弹出全键盘而非数字键盘 - 某些 Android WebView（尤其基于 Chromium 旧版本）会忽略
type="time"，直接 fallback - 若页面加载时 JS 报错中断，动态插入的
input可能未正确设置type属性，DOM 中实际是type="undefined"或空字符串
input type="time" 显示 AM/PM 却要求 24 小时制输入
这不是 bug，是设计使然：type="time" 完全由操作系统区域设置驱动，浏览器不提供任何属性强制切换格式。你在美式系统看到 1:30 PM，在中文系统看到 13:30，两者都合法，且提交值始终是 ISO 格式 "13:30"。
问题在于用户输入体验割裂：前端要求“只能填 24 小时制”，但 UI 却引导用户输 2:30 PM，结果校验失败。
立即学习“前端免费学习笔记（深入）”；
-
pattern、step、CSS 都不能改变 UI 显示格式——MDN 明确标注“no formatting control” - JS 设置
el.value = "14:30"能确保值正确，但 UI 仍按系统 locale 渲染，用户可能误改 - 真正可控的方案是放弃原生
type="time"，改用type="text"+inputmode="numeric"+ 实时格式化（如输入1430自动转为14:30）
input type="time" 值为空但表单能提交
required 属性只检测字段是否被“聚焦过”或“有用户交互”，不校验内容是否符合时间格式。用户点开又点走、或输入 25:70 这种非法值，checkValidity() 仍可能返回 true，因为浏览器对 type="time" 的内置验证非常宽松。
更隐蔽的问题是：移动端某些 WebView 对空值判断异常，el.value 返回空字符串但 el.checkValidity() 却返回 true。
- 不要依赖
required做唯一校验，提交前必须手动检查el.value是否匹配/^[0-2][0-9]:[0-5][0-9]$/ - 避免用
el.valueAsNumber判断有效性——非法时间（如"99:99"）会返回NaN，但空值也可能返回NaN，无法区分 - 服务端必须二次校验，不能信任前端
value字符串——浏览器允许用户手动修改 input 的 value 属性绕过所有限制
input type="time" 在 iOS 上 touch 后无法唤起时间选择器
iOS Safari 对 type="time" 的触发逻辑极其敏感：如果父容器有 transform、perspective、position: fixed，或 input 本身设置了 z-index、opacity: 0.99，都可能导致点击穿透或事件拦截，表现为“点了没反应”。
这不是 JS 事件没绑定，而是底层原生控件压根没收到触摸信号。
- 移除所有父级的
transform和will-change，尤其是transform: translateZ(0)这类“优化”写法 - 确保
input没有pointer-events: none，且z-index大于所有兄弟元素 - 不要用
focus()强制唤起——iOS 不响应 JS 触发的 focus 来打开时间选择器，必须真实用户点击 - 真机调试时用 Safari 开发者工具勾选 “Disable visual viewport”，有时能暴露被遮挡的渲染层
type="time" 是个“看天吃饭”的控件，它的行为取决于设备、系统、浏览器版本、甚至当前系统语言设置。你越想靠 CSS 或 JS 去“修复”它，越容易掉进兼容性陷阱。真正稳定的方案，是早做降级预案——当检测到 type="time" 不可用时，立刻切到受控文本输入，并把格式化逻辑收归自己手里。 
