datetime-local 的值是 iso 8601 字符串，直接 new date() 会误按 utc 解析致时区偏差；需补本地偏移或用 dayjs/luxon 显式指定时区；旧 safari 不支持，firefox 时间输入无滚动器；后端须约定时区处理并注意 url 编码。
datetime-local 的值永远是字符串，不是 Date 对象
直接用 new Date(input.value) 会出错——浏览器返回的 value 是类似 "2026-05-09T13:54" 的 ISO 8601 字符串，JS 解析时默认按 UTC 处理，导致东八区时间变成 UTC+0，偏差 8 小时。比如你选的是「北京时间 13:54」，new Date("2026-05-09T13:54") 实际构造的是「UTC 时间 13:54」，即北京时间 21:54。
正确做法是手动补全本地时区偏移：
- 用
Intl.DateTimeFormat().resolvedOptions().timeZone获取用户时区名（如"Asia/Shanghai"） - 或用
new Date().getTimezoneOffset()算出分钟偏移（如 -480），再拼成"2026-05-09T13:54:00-08:00"格式再解析 - 更稳妥：用
dayjs或luxon的fromISO(..., { zone: 'local' })显式声明本地上下文
移动端 Safari 支持从 iOS 14.5 开始，旧版直接降级为 text
iOS 14.4 及更早版本的 Safari 完全不识别 type="datetime-local"，会回退成普通 <input type="text">，既无选择器，也无格式校验。用户只能手输，且容易输错格式（比如漏掉 T、用中文冒号、加秒等）。
检测是否真正可用，不能只靠 "datetime-local" in document.createElement("input").type——这在旧 Safari 里也返回 true，但实际无效。可靠判断方式是：
- 创建临时 input 元素，设
type = "datetime-local" - 检查
input.type是否仍为"datetime-local"（而非被强制转成"text"） - 再检查
input.hasAttribute("type")和getComputedStyle(input).appearance是否含"textfield"（说明已降级）
Chrome/Edge 支持完整，但 Firefox 桌面端默认不显示时间滚动器
Firefox 自 99 版本起支持 datetime-local，但它的 UI 不提供小时/分钟滚动选择，只弹出日历 + 文本框让用户手动输入时间部分。这意味着用户必须自己键入 13:54，没有防错机制，也无法用键盘上下键微调。
如果你依赖精确到分钟的操作体验，不能假设所有“支持”的浏览器都提供相同交互。解决方案包括：
- 对 Firefox UA 单独加 JS 补充时间选择逻辑（如监听
input事件，校验时间格式并自动补零） - 用
step="300"（5 分钟步长）限制输入粒度，降低手动输入错误率 - 配合
min和max属性做服务端+客户端双重约束，避免极端值
后端接收前必须确认时区约定，否则数据意义丢失
datetime-local 的值本身不含时区信息，它只是「用户本地日历上的一个时间点」。同一个字符串 "2026-05-09T13:54"，在北京代表 UTC+8 的 13:54，在洛杉矶代表 UTC-7 的 13:54——两者相差 15 小时。
所以后端绝不能直接存这个字符串当时间戳用。必须明确约定：
- 前端在提交前主动加上本地时区偏移（如
"2026-05-09T13:54:00+08:00"），后端按带时区 ISO 解析 - 或统一转为 UTC 时间戳（毫秒数）再传，后端只收数字
- 或前后端约定「所有 datetime-local 值均按服务器所在时区解释」，但需在表单旁显式提示用户「请按[XX时区]时间填写」
最容易被忽略的是：GET 请求中 : 需 URL 编码为 %3A，否则参数截断。例如 ?at=2026-05-09T13%3A54 才合法。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
