HTML5原生支持5种日期类型：date、month、week、time、datetime-local；其value值均为固定ISO格式字符串，不自动转为Date对象，且各类型输入格式严格受限，废弃的datetime不可用。
HTML5 原生支持的日期类型只有 5 种，且全部通过 暴露，浏览器原生控件行为、可输入格式、JS 获取值方式各不相同——别指望用 type="date" 输入 “2023-03-15 14:30” 这种带时间的字符串，它根本不会接受。
哪些 type 值算“日期相关”？
W3C 明确定义为日期/时间类的 type 共 5 个：
-
date：年-月-日（如2023-09-25） -
month：年-月（如2023-09） -
week：年-W周号（如2023-W39，注意是大写 W） -
time：时:分 或 时:分:秒（如14:30或14:30:22） -
datetime-local：年-月-日T时:分 或 年-月-日T时:分:秒（如2023-09-25T14:30）
注意：datetime（带时区）已被废弃，type="datetime" 在所有现代浏览器中等价于 text，不要用。
value 属性和 JS 获取值的格式是固定的
无论用户怎么选、怎么输（只要合法），input.value 返回的永远是规范化的 ISO 8601 字符串，不含本地时区偏移（datetime-local 除外）：
立即学习“前端免费学习笔记（深入）”；
-
→input.value是"2023-09-25" -
→input.value是"14:30"（秒位补零后为"14:30:00"） -
→input.value是"2023-09-25T14:30"（不带 Z，也不转本地时区）
这意味着你不能靠 input.value 直接拿到 Date 对象，必须手动解析；也意味着后端接收时，要按 ISO 格式严格校验，不能依赖浏览器“帮你转时区”。
用户能输什么？浏览器怎么验证？
用户手动输入时，浏览器只接受与 type 匹配的 ISO 子集格式，其他一律视为无效（input.checkValidity() 返回 false）：
-
date：只认YYYY-MM-DD，2023/09/25或25-09-2023会触发invalid事件 -
month：只认YYYY-MM，2023.09不行 -
week：必须是YYYY-W##，2023-39不行（缺 W） -
time：支持HH:MM和HH:MM:SS，但HH.MM或HH:MM:SS.sss（毫秒）会被拒绝 -
datetime-local：必须含T，2023-09-25 14:30（空格）无效
提示：Chrome/Firefox 的原生弹出控件会自动补全格式，但 Safari 对 week 和 datetime-local 支持较弱，部分机型无弹窗，得靠用户手输——务必加 required 和前端校验逻辑。
兼容性与 fallback 策略
IE 完全不支持所有这些 type，旧版 Safari 对 week、datetime-local 渲染为文本框。稳妥做法是：
- 用
Modernizr.inputtypes.date或document.createElement('input').type = 'date'检测支持性 - 不支持时，降级为
type="text"+ 第三方 picker（如 flatpickr、Pikaday） - 避免用
placeholder暗示格式（如placeholder="YYYY-MM-DD"），因为原生控件不显示 placeholder - 服务端永远不要信任客户端传来的日期字符串格式，必须用严格正则或 Date 解析器二次校验
最常被忽略的一点：所有这些 type 的 min/max 属性也必须用同样 ISO 格式书写，比如 min="2023-01-01"，写成 min="01/01/2023" 就失效。
