应避免直接在生产环境使用 input[type="datetime-local"]，因其在旧版 Safari/iOS 中会降级为文本框且缺乏校验；需通过 type 比较与 appearance 检测双重验证真实支持性；值必须严格符合 ISO 8601 格式（YYYY-MM-DDTHH:MM），否则浏览器静默清空；解析时需注意时区，默认按 UTC 解析，建议用 dayjs 或 luxon 处理本地时区；iOS Safari 16.3 及更早版本不支持该类型，应降级为 date+time 双控件并同步 min/max；核心是保障用户输入合法时间值且时区上下文全程一致。
别直接用 input[type="datetime-local"] 上生产，除非你已明确控制用户浏览器范围且能接受 Safari/iOS 旧版降级为文本框。
检测是否真支持 datetime-local，而不是“假装支持”
仅检查 "datetime-local" in document.createElement("input").type 是无效的——旧版 Safari 会返回 true，但实际渲染成 type="text"。必须做双重验证：
- 创建临时
input元素，设type = "datetime-local" - 检查
input.type === "datetime-local"（排除被强制转成"text"） - 再调用
getComputedStyle(input).appearance，若含"textfield"或为空字符串，说明已降级
示例检测函数：
function isDateTimeLocalTrulySupported() {
const el = document.createElement("input");
el.type = "datetime-local";
if (el.type !== "datetime-local") return false;
const appearance = getComputedStyle(el).appearance;
return appearance && !appearance.includes("textfield");
}
值格式写错一秒，输入框就清空
datetime-local 的 value 必须是严格 ISO 8601 格式：YYYY-MM-DDTHH:MM（注意是大写 T，不能有空格、中文冒号、秒、毫秒或时区后缀）。任何偏差都会导致浏览器静默清空输入框：
立即学习“前端免费学习笔记（深入）”；
- ❌
"2026-06-18 10:52"（空格代替T） - ❌
"2026-06-18T10:52:00"（带秒，未显式设step="1"） - ❌
"2026-06-18T10:52+08:00"（含时区，浏览器不认） - ✅
"2026-06-18T10:52"（精确到分，补零）
从 Date 实例生成安全值推荐用：date.toLocaleString("sv-SE", { hour12: false }).replace(" ", "T") —— 这保留用户本地意图，不转 UTC。
用户选完后 new Date(value) 会跨时区偏移 8 小时
直接 new Date("2026-06-18T10:52") 在所有主流浏览器中都解析为「UTC 时间 10:52」，即北京时间 18:52。这不是 bug，是规范行为：该字符串无时区标识，默认按 UTC 解析。
- 最轻量修复：补全本地时区上下文，
new Date(input.value + ":00" + getTimezoneOffsetString())（需手动拼偏移） - 更稳方案：用
dayjs(input.value).local()或luxon.DateTime.fromISO(input.value, { zone: "local" }) - 如果后端统一按东八区处理，可硬编码补
"+08:00"：new Date(input.value + "+08:00")
注意：input.valueAsNumber 在 Firefox 不支持，不能依赖。
移动端 Safari 16.3 及更早版本根本没选择器
iOS Safari 直到 16.4 才完整支持 datetime-local；16.3 及更早版本会回退为纯 type="text"，无校验、无弹窗、用户可输任意内容（如 "hello"），后端收到就是乱码。
- 降级策略不是“加个 polyfill”，而是彻底替换：对不支持的 UA，改用
date+time双控件组合 - 双控件需动态同步
min/max：比如日期选了"2026-06-18"，时间控件的min应设为当天 00:00，避免出现"2026-06-18T25:00" - 不要用第三方库“强行覆盖”，优先保证表单语义和可访问性；Flatpickr 等库在 iOS 上仍可能触发软键盘而非系统时间选择器
真正难的不是实现，是意识到：所谓“兼容”，不是让所有浏览器都用同一个 UI，而是让所有用户都能以符合其设备习惯的方式，输入合法、有意义的时间值——而这个值，必须在首次赋值、用户修改、提交解析三个环节都保持时区上下文一致。
