datetime-local 浏览器兼容性差：Chrome/Edge 支持完整选择器，Firefox 仅日历+手动输时间，Safari iOS 16.3 及更早降级为 text；需运行时检测（type === 'datetime-local' 且 appearance !== 'textfield'），失败则用 date+time 双控件或 Flatpickr 降级，并补秒和本地偏移解析 value。
datetime-local 在 Chrome/Firefox/Safari 中渲染差异明显
Chrome 和 Edge 会显示带日历+时间滚动器的完整选择器，Firefox 只弹日历 + 手动输入时间框（无滚动），Safari 桌面端尚可，但 iOS 16.3 及更早版本直接降级为 type="text"，连基本格式校验都没有。这不是 bug，是浏览器对 HTML5 规范的不同实现程度。
你不能靠 CSS 强行统一外观——appearance 在 Safari 上受限，::-webkit-datetime-edit 等伪元素在 Firefox 和旧 Safari 中无效，强行覆盖反而导致交互失灵。
- 别写
input[type="datetime-local"] { appearance: none; }—— Safari 会丢掉原生选择器，用户只能手输 - 别用
!important覆盖background或padding—— Chrome 下可能遮挡时间滚动箭头 - Firefox 不响应
step="300"（5 分钟步长），但 Chrome 支持；设了也白设
如何检测 datetime-local 是否真正可用
仅检查 "datetime-local" in document.createElement("input").type 是错的——旧 Safari 返回 true，但实际渲染为文本框。必须做运行时检测：
function isDateTimeLocalSupported() {
const input = document.createElement('input');
input.type = 'datetime-local';
return input.type === 'datetime-local' &&
getComputedStyle(input).appearance !== 'textfield';
}
这个判断能筛出 iOS 16.3 及更早、部分安卓 WebView 场景。返回 false 时，你就该启用降级方案。
立即学习“前端免费学习笔记（深入）”；
- 检测必须在 DOM ready 后执行，避免 SSR 环境误判
- 不要缓存结果：用户可能中途切换浏览器或系统设置
- 若检测失败，建议立即替换为
<input type="text">+ Flatpickr，而非留空或静默 fallback
value 解析错误：new Date(input.value) 为什么总差 8 小时
input.value 是字符串，如 "2026-06-16T19:54"，直接传给 new Date() 会被当作 UTC 时间解析。东八区用户选的「19:54」，JS 解析成 UTC 的 19:54，即北京时间次日 03:54 —— 差整整 8 小时。
正确做法是补全秒和本地偏移：
const dtStr = input.value; // "2026-06-16T19:54" const date = new Date(dtStr + ":00"); // 补 ":00" → 浏览器按本地时区解析 const timestamp = date.getTime(); // 得到正确毫秒数
- 别用
input.valueAsNumber：Firefox 不支持，返回NaN - 别依赖
toLocaleString()格式化后再 parse：不同语言环境输出格式不一致（如 en-US 输出 "6/16/2026, 7:54 PM"） - 后端若需 UTC 时间戳，建议前端拼
input.value + "+08:00"（按业务所在时区硬编码），比依赖浏览器自动换算更可控
移动端 Safari 16.4 以下必须放弃原生控件
iOS 16.3 及更早的 Safari 对 datetime-local 的支持是“名义支持”：type 属性存在，但 UI 渲染、change 事件触发、value 更新全部不可靠。用户输 "2026-06-16 19:54"，input.value 可能为空或乱码，且不会触发 change。
真实可行的底线策略只有两个：
- 用
date+time双控件组合：iOS 全版本都支持，且各自有原生选择器，再用 JS 合并值（注意time输入无日期上下文，需显式绑定） - 直接引入轻量 JS 库（如
flatpickr），禁用原生控件：<input type="text" data-flatpickr>，避免任何datetime-local相关逻辑被执行
跨系统样式差异的本质不是视觉问题，而是行为一致性缺失。修复重点不在“让它看起来一样”，而在“让它在所有设备上都能可靠地选、可靠地传、可靠地解析”。
