HTML 在 Safari 旧版本（iOS 16.4/macOS Ventura 13.3 前）未真正实现，仅回退为文本框且无校验、min/max/value 失效；需运行时检测并提前降级至 JS 日期选择器，注意时区、格式与服务端双重校验。
HTML
这意味着如果你的用户有大量 iPhone 或旧版 Mac 用户， 在 Safari 里要么不显示控件、要么退化成文本框，且无法保证输入格式。不是“兼容性差”，而是“部分版本压根没实现”。
常见错误现象：
– 页面上明明写了 ，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 插入
+ 初始化插件 - 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 旧版中完全被忽略
即便你写了 ，在 iOS 15 及更早版本中，这些属性不会生效——既不限制可选范围，也不预设初始值。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
-
min和max只影响原生 picker 的可选区间，不影响手动输入（这点所有浏览器都一样） - 设置
value必须是完整合法的 ISO 日期字符串（如"2023-05-20"），写成"2023/05/20"或"20-05-2023"会导致值为空 - 服务端永远要二次校验：前端限制只是体验优化，不能替代
YYYY-MM-DD格式和日期有效性检查
提交表单时，后端收到的日期字符串总是 YYYY-MM-DD，但时区隐含零点
无论用户在哪一时区、选的是哪天， 提交的值都是形如 "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。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
