datetime-local 输入框只存储无时区的“年月日时分”字符串（如2024-05-20T14:30），浏览器按本地时区渲染但提交原格式，后端不可直接解析为UTC或服务器时间，需显式绑定本地时区转换。
type=datetime-local 的值格式和时区陷阱
它不存 UTC，也不存本地时区偏移，只存“无时区的年月日时分”字符串，比如 2024-05-20T14:30。浏览器渲染时按用户本地时区显示，但提交时仍按这个本地化格式发给后端——这意味着：同一台机器选的值，不同地区用户看到的“14:30”实际对应的真实时间可能差好几小时。
- 后端收到
2024-05-20T14:30不能直接当 UTC 解析，也不能直接当服务器本地时间用 - 如果页面部署在跨时区服务（如 CDN 或多区域负载），用户看到的“当前时间”初始值可能错乱
-
new Date(input.value)在 Chrome/Firefox 中会按本地时区解释该字符串，但 Safari 早期版本可能返回 Invalid Date
设置默认值必须用 ISO 格式，且不含 Z 或 ±offset
给 input[type="datetime-local"] 设 value，只能是形如 YYYY-MM-DDTHH:MM 的字符串，且不能带时区标识。哪怕你传了 2024-05-20T14:30:00Z，浏览器会清空输入框或忽略该值。
- 正确写法：
input.value = "2024-05-20T14:30"（注意秒可省略） - 从 Date 实例转过来要手动格式化：
date.toISOString().slice(0, 16)（截掉秒和 Z） - 用
toLocaleString()拼接会出错——它返回的是带空格、逗号、中文的字符串，浏览器根本不认
获取用户选择后如何转成可靠的时间戳
直接读 input.value 得到的是字符串，想转成毫秒数必须补全时区信息。最稳妥做法是：把它当作“用户本地意图时间”，显式绑定到当前时区再解析。
- 推荐方案：
new Date(input.value + ":00")—— 补上秒和冒号，让所有浏览器都能 parse（Chrome/Firefox/Safari 均支持） - 避免
new Date(input.value)：Safari 15.4 之前对T分隔符支持不稳定 - 如果需存为 UTC 时间戳，应调用
date.getTime()（Date实例内部始终是毫秒数，与构造方式无关） - 注意：
date.toLocaleString()输出不可靠，不要用于传输或比较
移动端兼容性和 fallback 方案
iOS Safari 直到 16.4 才完全支持 type="datetime-local"，更早版本会降级为 text 输入框，且不弹日期选择器；Android WebView 表现也参差不齐。
立即学习“前端免费学习笔记（深入）”；
- 检测是否可用：
"datetime-local" in document.createElement("input").types - fallback 推荐用两个分离的
input[type="date"]和input[type="time"]，拼接时注意时分补零（如"09"而非9） - 不要依赖 polyfill 库自动替换——它们常绕过原生事件、破坏表单验证逻辑
- 服务端必须校验字段格式，不能信任前端传来的任何
datetime-local值
真正麻烦的不是怎么写，而是它天生不告诉你“这时间属于哪个时区”。只要涉及跨用户、跨设备、跨服务的时间协同，就必须在业务层明确约定解释规则，而不是指望浏览器替你决定。
