HTML <input type="date"> 在 Safari 旧版本（iOS 16.4/macOS Ventura 13.3 前）未真正实现，仅回退为文本框且无校验、min/max/value 失效；需运行时检测并提前降级至 JS 日期选择器，注意时区、格式与服务端双重校验。
HTML <input type="date"> 在 Chrome/Firefox/Edge 中能直接用，但 Safari 直到 iOS 16.4 和 macOS Ventura 13.3 才真正支持
这意味着如果你的用户有大量 iPhone 或旧版 Mac 用户，<input type="date"> 在 Safari 里要么不显示控件、要么退化成文本框，且无法保证输入格式。不是“兼容性差”，而是“部分版本压根没实现”。
常见错误现象：
– 页面上明明写了 <input type="date">，Safari 里却只显示普通文本框
– 用户手动输入 2023-13-01，浏览器不校验（其他浏览器会拒收）
– value 返回空字符串，即使 DOM 上看着有值
- 使用场景：管理后台内部工具（Chrome 主力）可直接用；面向公众的表单必须降级处理
- 检测是否可用：运行
const input = document.createElement('input'); input.type = 'date'; console.log(input.type === 'date');，返回true才算真支持 - 不要依赖
Modernizr等旧库判断——它们常把 Safari 的“声明支持”误判为“可用”
如何安全 fallback 到 JS 日期选择器（比如 flatpickr）
不能等 type="date" 失效后再加载 JS 插件，否则页面闪动、焦点丢失、移动端软键盘反复弹起。得在初始化阶段就决策。
- 先执行检测逻辑，再决定渲染原生控件 or 插入
<input type="text">+ 初始化插件 - flatpickr 默认不校验格式，要显式传
allowInput: true并配合onParseConfig或外部校验，否则用户粘贴2023/02/30也能过 - 注意时区：原生
input[type=date]的value永远是 UTC 零点（ISO 格式YYYY-MM-DD），而 flatpickr 默认按本地时区解析，getDate()返回 Date 对象可能偏移一天 - 移动端需加
inputmode="numeric"和pattern="[0-9]{4}-[0-9]{2}-[0-9]{2}"，引导系统键盘显示数字布局
min / max / value 属性在 Safari 旧版中完全被忽略
即便你写了 <input type="date" min="2023-01-01" value="2023-05-20">，在 iOS 15 及更早版本中，这些属性不会生效——既不限制可选范围，也不预设初始值。
立即学习“前端免费学习笔记（深入）”；
-
min和max只影响原生 picker 的可选区间，不影响手动输入（这点所有浏览器都一样） - 设置
value必须是完整合法的 ISO 日期字符串（如"2023-05-20"），写成"2023/05/20"或"20-05-2023"会导致值为空 - 服务端永远要二次校验：前端限制只是体验优化，不能替代
YYYY-MM-DD格式和日期有效性检查
提交表单时，后端收到的日期字符串总是 YYYY-MM-DD，但时区隐含零点
无论用户在哪一时区、选的是哪天，<input type="date"> 提交的值都是形如 "2023-05-20" 的字符串，对应 UTC 时间 2023-05-20T00:00:00Z。这不是 bug，是规范行为。
- 如果你需要“用户本地当天”的语义（比如生日、预约日），这个值刚好合适；但如果是“截止时间”，就得额外存小时分钟，或改用
datetime-local（注意：Safari 同样长期不支持） - Node.js 接收后用
new Date(req.body.date)会变成用户本地时区的凌晨，容易出错；推荐用date-fns/parseISO或dayjs(dateString)显式按 UTC 解析 - 数据库字段类型建议用
DATE（非DATETIME），避免时区混淆
最麻烦的不是怎么写，而是得时刻记住：这个控件天生没时区概念，也没“今天”“明天”这类相对值支持，所有业务逻辑里的“相对日期”都得前端算好再塞进 value。
