原生日期时间控件必须严格使用标准格式：date为“yyyy-mm-dd”，time为“hh:mm”，datetime-local为“yyyy-mm-ddthh:mm”；三者均无时区，提交为本地字符串，需js处理时区转换；兼容性差时应降级为type="text"+pattern。
用 type="date" 选年月日，别碰 value 格式以外的字符串
浏览器只认 "YYYY-MM-DD" 格式的 value，比如 value="2026-09-05"。写成 "2026/09/05"、"05-09-2026" 或带时间的 "2026-09-05T10:00"，输入框会清空或忽略该值。
- 提交时后端收到的是纯字符串，不是时间戳，也不含时区 —— 别用
new Date(input.value)直接解析，否则在不同时区可能跨天 -
min和max也必须是同样格式，且不能让min > max，否则某些浏览器（如 Safari）会禁用整个控件 - 移动端点开就是系统原生日历，体验比 JS 插件更轻量，但旧版 IE 和部分安卓 WebView 不支持，需特性检测
用 type="time" 只管“时刻”，和日期完全无关
type="time" 的值永远是 "HH:mm" 或 "HH:mm:ss"，它不记录哪一天、也不带时区。用户在北京输 14:30，和在纽约输 14:30，语义完全不同。
- 别把它和
date字段简单拼接成 ISO 字符串 —— 容易漏掉T分隔符，或没补零，比如拼出"2026-09-0514:30"而非"2026-09-05T14:30" -
input.valueAsDate对time类型返回的日期对象，日期部分恒为1970-01-01，仅时间有效，别误当完整时间用 - 若需“某日某时刻”语义，优先用
datetime-local；若只要固定时段（如“每天 9:00 开始”），time才合适
用 type="datetime-local" 时，记住它没有时区，也不能设时区
这是唯一原生支持“日期 + 时间”的类型，值格式为 "YYYY-MM-DDTHH:mm"，但浏览器始终按用户本地时区渲染和解释。你传 value="2026-09-05T14:30+08:00"，它会自动截掉 +08:00 部分，只留 "2026-09-05T14:30"。
- 提交到后端的仍是本地时间字符串，不是 UTC；需要统一时区时，必须用 JS 转：
new Date(input.value).toISOString().slice(0, 19) - Safari 在 iOS 15.4 之前完全不支持，降级后显示为普通文本框，且无任何验证 —— 必须加
pattern或用 JS 检测并加载 fallback 插件 -
min/max值也必须是本地时间格式，不能混用 UTC 字符串，否则行为不可预测（Chrome 可能接受，Firefox 可能忽略）
兼容性差的时候，别硬扛，用 type="text" + pattern 是最可控的兜底方案
当目标环境包含大量旧版浏览器或定制 WebView（比如某些银行 App 内嵌页），强行用原生控件反而导致表单失效。这时 type="text" 配合 HTML5 验证属性反而是更稳的选择。
-
pattern="[0-9]{4}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])"能阻止非法格式提交，配合title提示用户 - 用
inputmode="numeric"在移动端唤起数字键盘，提升输入效率 - 真正难处理的是逻辑校验（比如 2026-02-30 合法吗？闰年怎么算？），这部分必须靠 JS 补全，不能只依赖 pattern
value 和提交字符串是两套逻辑，中间没有隐式转换。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
