input type="time" 在 Safari 中不支持，会退化为文本框；value 必须严格为 "HH:MM" 格式（如 "09:30"），否则为空；min/max 失效；需用 JS 动态赋值并检测支持性，跨时区合并时间应避免前端拼接。
input type="time 不是“学完就能用”，而是“用时必须踩准几个点”。Safari（含 macOS 和 iOS）至今不支持原生控件，会退化成纯文本框；value 格式稍有偏差（比如 "9:30" 而非 "09:30"），整个输入框就变空；min/max 限制在 Safari 中完全失效。别指望一次写对，得按真实环境来调。
为什么 value="9:30" 会显示为空？
浏览器对 input type="time" 的 value 属性执行严格字符串匹配：只接受 "HH:MM" 格式（24 小时制、两位小时、两位分钟、英文冒号）。以下都会失败：
-
"9:30"（小时缺前导零） -
"09:30:00"（多了秒） -
"09:30 "（末尾空格） -
"09-30"（用了短横线）
后端返回的 "9:30" 或 JS 中拼出的 hours + ':' + minutes 必须补零：timeStr.padStart(5, '0') 或 `${h.toString().padStart(2,'0')}:${m.toString().padStart(2,'0')}`。直接写死 HTML 的 value 属性风险高，推荐用 JS 赋值：el.value = formattedTime。
如何检测 Safari 并降级？
不能靠 Modernizr 或 UA 字符串判断——UA 可伪造，Modernizr 检测已过时。最稳的方式是创建一个临时元素并检查其 type：
const el = document.createElement('input');
el.type = 'time';
const isTimeSupported = el.type === 'time';
若 isTimeSupported === false（即 Safari / 旧 Firefox），就替换为 select 下拉或轻量 JS 时间选择器（如仅用 hour 和 minute 两个 select）。别用 CSS :invalid 伪类做 fallback 判断，它在 Safari 中根本不起作用。
立即学习“前端免费学习笔记（深入）”；
监听用户输入该用 input 还是 change？
用 input 事件。原因很实际：
-
change只在用户确认后触发（比如点“完成”或失焦），无法响应滚动过程中的实时变化 -
input在每次键盘输入、滚轮滚动、点击箭头时都触发，适合做格式校验、联动禁用其他字段、或实时预览 - Safari 因无原生控件，
change行为更不可靠，而input对文本框始终有效
示例：
timeInput.addEventListener('input', () => {
if (timeInput.value && !/^\d{2}:\d{2}$/.test(timeInput.value)) {
showCustomError('请输入 HH:MM 格式，如 14:30');
}
});
和 input type="date" 搭配使用时怎么合并值？
不要简单拼接字符串，否则跨时区解析会错乱。例如：dateInput.value + 'T' + timeInput.value 得到 "2026-10-01T14:30"，但 new Date("2026-10-01T14:30") 会按用户本地时区解释，纽约用户看到的是 EDT，上海用户看到的是 CST，同一字符串含义不同。
稳妥做法是显式指定时区偏移（按业务约定）：
- 若统一用东八区：
dateInput.value + 'T' + timeInput.value + '+08:00' - 若存 UTC：
new Date(dateInput.value + 'T' + timeInput.value).toISOString()（注意：此方法依赖用户本地时区转换，仅适用于用户与服务端同区或可接受误差）
真正安全的合并逻辑应在后端完成，前端只传两个独立字段。
关键不是“会不会写type="time"”，而是你是否意识到：Safari 用户看到的是文本框，value 格式错一位就归零，min/max 是摆设，跨时区拼时间字符串等于埋雷。这些不是边缘情况，是每天上线后真实报错的来源。 
