是HTML5中唯一原生支持日期以及时分秒选择的控件，格式为YYYY-MM-DDThh:mm[:ss]，不带时区，Chrome/Edge/Firefox≥104支持，Safari至今不支持，需降级处理。
HTML5 中
直接用 只能选年月日，不带时间；想同时选日期和时分秒，必须用 datetime-local。它在 Chrome、Edge、Firefox（104+）中已稳定支持，但 Safari 目前仍不支持（截至 iOS 17.5 / macOS 14.5），这点容易被忽略。
示例写法：
注意：datetime-local 不包含时区信息，值格式为 YYYY-MM-DDThh:mm 或 YYYY-MM-DDThh:mm:ss（秒可选，但浏览器通常会显示并提交秒）。
value 属性必须用标准 ISO 格式，且需补零、无空格、无中文标点
设置默认值时，如果格式错一个字符（比如用中文冒号、缺零、多空格），浏览器会直接忽略该值，输入框显示为空或回退到当前时间。
立即学习“前端免费学习笔记（深入）”；
- ✅ 正确：
value="2024-06-15T14:30"或value="2024-06-15T14:30:22" - ❌ 错误：
value="2024/06/15 14:30"（斜杠、空格）、value="2024-6-15T14:30"（月/日未补零）、value="2024-06-15T14：30"（中文冒号）
后端传值给前端时，务必用 toISOString().slice(0, 16)（取到分钟）或 slice(0, 19)（含秒），避免手动拼接出错。
提交时的值不含时区，但解析时按本地时区解释，跨时区场景要特别小心
用户选择 2024-06-15T14:30，表单提交的就是这个字符串 —— 它没有 Z 或 +08:00，但浏览器内部是按用户本地时区理解的。比如上海用户选的 14:30，实际对应 UTC 时间 06:30；而纽约用户选同一串值，会被当成 EDT 的 14:30（即 UTC 18:30）。
这意味着：
- 如果你需要服务端统一按 UTC 存储，不能直接存
datetime-local提交的值 - 建议前端用
new Date(input.value).toISOString()转成带 Z 的 UTC 字符串再提交 - 后端收到
datetime-local值时，应明确按客户端所在时区解析，而非当作 UTC 处理
不支持 datetime-local 的浏览器（如 Safari）需要降级方案
Safari 一直没实现该类型，iOS 和 macOS 用户看到的是普通文本框，无法唤起时间选择器。不能只靠 CSS 或 placeholder 欺骗用户。
稳妥做法是检测支持性并动态替换：
const input = document.querySelector('input[type="datetime-local"]');
if (!input.type === 'datetime-local') {
// 创建两个独立控件：
// +
// 或引入轻量库如 flatpickr（开启 enableTime: true）
}
注意：不要用 —— 它已被 HTML5 废弃，所有现代浏览器都不支持。
真正麻烦的不是写法，而是时区语义模糊 + Safari 缺失 + 后端解析逻辑不一致，这三者叠在一起，比格式本身容易出问题得多。
