datetime-local 输入框需严格使用 yyyy-mm-ddthh:mm 格式，safari/ios 旧版不支持，降级为文本框；兼容方案是 date+time 双控件，min/max 须动态生成以避免时区偏差。
别直接用 input[type="datetime-local"] 上生产，除非你已明确控制用户浏览器范围且能接受 Safari/iOS 旧版降级为文本框。
为什么 datetime-local 的 value 必须是 YYYY-MM-DDTHH:MM 格式
浏览器只认这个精确字符串：不能少 T，不能带秒（除非你显式加 step="1"），不能有空格或中文，更不能带 Z 或 +08:00。传错就清空输入框——比如 "2024-05-20 14:30" 或 "2024-05-20T14:30:00Z" 都会失效。
设置默认值的正确写法：
const el = document.querySelector('input[type="datetime-local"]');
el.value = "2026-05-18T15:24"; // 当前时间手动截取到分，注意补零
从 Date 实例生成该格式最稳的方式是：
-
date.toISOString().slice(0, 16)（自动转成 UTC 时间再截，适合后端统一按 UTC 存） - 若要保留用户本地意图（推荐），先用
date.toLocaleString("sv-SE", {hour12: false})得到"2026-05-18 15:24"，再手动替换空格为T
用户选完后怎么转成可靠的时间戳
直接 new Date(input.value) 在 Safari 15.4 之前可能返回 Invalid Date；用 input.valueAsNumber 又只在 Chrome/Edge 有效，Firefox 不支持。
稳妥方案是补全秒和时区上下文：
-
new Date(input.value + ":00")—— 补:00让所有主流浏览器都能 parse 成本地时间的Date实例 - 再调用
.getTime()得到毫秒数（内部始终是 UTC 毫秒，与构造方式无关） - 如果需存为 UTC 时间戳并显式标注偏移，建议后端统一按
input.value + "+08:00"（按你业务所在时区硬编码）解析，避免依赖浏览器自动换算
移动端和 Safari 兼容性差的真实表现
iOS Safari 直到 16.4 才完整支持 datetime-local，16.3 及更早版本直接渲染为 type="text"，不弹选择器，也不限制输入格式——用户能随便输 "hello"，后端收到就是乱码。
检测是否可用的最小成本判断：
const isDateTimeLocalSupported = "datetime-local" in document.createElement("input").types;
不支持时，fallback 方案不是“加 polyfill”，而是拆成两个控件：
-
<input type="date">+<input type="time"> - 用
display: flex; gap: 8px横向对齐，加aria-label保证可访问性 - 拼接时必须补零：
dateValue + "T" + timeValue.padStart(5, "0")（因为"9:30"要变成"09:30"）
min/max 属性的坑比想象中深
min 和 max 值也必须是 YYYY-MM-DDTHH:MM 格式，且浏览器按本地时区解释它们——比如你设 min="2026-05-18T00:00"，在东京用户看来是 5 月 18 日 0 点，在洛杉矶用户看来却是 5 月 17 日下午 4 点。
这意味着：
- 跨时区服务中，
min实际生效时间不一致 - 不要用服务端时间动态写死
min，而应由前端根据new Date()动态生成并格式化 - 若需强制约束为“今天及以后”，每次页面加载都执行：
el.min = new Date().toISOString().slice(0, 16)
真正麻烦的从来不是怎么写那一行 HTML，而是你没意识到：同一个字符串，在不同设备上代表的时间点可能差一整天。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
