Safari 15.4前及旧版Edge不支持，功能完全缺失；需检测showPicker或点击行为，降级为text+flatpickr；服务端必须严格校验日期格式与范围。
HTML <input type="date"> 在 Safari 和旧版 Edge 里根本点不开
这是最常被忽略的兼容性断点：Safari（包括 iOS）直到 15.4 才原生支持 <input type="date">，而旧版 Edge（EdgeHTML）压根不识别该类型，直接降级成普通文本框，连日历图标都不显示。
实际表现不是“样式不好看”，而是功能缺失——用户无法点选、无法用键盘输入合法日期格式、提交时也得不到浏览器校验。
- 不要依赖
Modernizr.inputtypes.date判断：它只检测属性存在，不保证 UI 可交互；Safari 14 返回true，但点击无响应 - 优先检测是否真正可交互：用
document.createElement('input').type = 'date';后检查input.type === 'date'且input.showPicker存在（Chrome/Edge 102+）或监听click后是否弹出原生日历（需人工验证） - 简单兜底方案：对不支持的环境，自动把
type改成"text"，并绑定一个轻量 JS 日期选择器（如flatpickr），避免全站引入大 polyfill
用 webcomponentsjs polyfill 补 <input type="date"> 是错的
webcomponentsjs 解决的是自定义元素和 Shadow DOM 兼容性，它完全不处理表单控件的语义增强。强行引入不仅没用，还会干扰已有表单逻辑，尤其在 Vue/React 中可能引发事件丢失。
真正需要的是「行为补全」而非「语法补全」：让不支持的浏览器获得日期输入能力，而不是模拟一个 Web Component 包裹的假控件。
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 别碰
document-register-element或custom-elements-es5-adapter：它们和日期输入无关 - 警惕「全自动 polyfill」方案（如某些 CDN 提供的
date-input-polyfill.js）：多数会劫持所有input[type=date]，覆盖掉你已写的初始化逻辑 - 推荐手动控制：只在检测到不支持时，动态加载
flatpickr并初始化，同时保留原生valueAsNumber/valueAsDate的读写接口一致性
服务端必须校验 input[type=date] 的值，前端校验形同虚设
即使用了 polyfill，用户仍可绕过 JS 直接修改 DOM 的 value 属性，或禁用 JS 后提交空值、非法格式（如 "2023-02-30"）。浏览器原生校验（required、min/max）在 polyfill 环境下基本失效。
关键不是“有没有校验”，而是“校验在哪一层生效”。前端只做即时反馈，服务端才是唯一可信边界。
- 后端收到的
date字段必须用严格解析函数处理（如 Node.js 用new Date(str)后检查isNaN()，再比对toISOString().slice(0,10)是否与输入一致） - 不要信任
valueAsDate：polyfill 通常不实现该属性，或返回null；统一走字符串解析路径更可靠 - 如果用 Form 表单提交，确保
name属性明确（如name="due_date"），避免和 JS 变量名混淆导致服务端收不到字段
移动端 iOS Safari 的 input[type=date] 有隐藏限制
iOS Safari 虽然支持该类型，但有两个硬伤：一是不响应 min/max 属性（滑动日历仍能选超范围日期），二是中文系统下默认显示农历（部分版本），导致 value 输出仍是 ISO 格式，但用户感知混乱。
这不是 bug，是 WebKit 的设计取舍：它把日期选择器视为“辅助输入工具”，而非强约束控件。
- 必须用 JS 补充
change事件监听，拿到值后立刻校验是否在min/max范围内，否则就重置value - 避免在
placeholder里写“请选择日期”——iOS 不显示 placeholder，留白容易让用户误以为没加载出来 - 如果业务强依赖农历或节假日逻辑，别指望浏览器原生控件，直接上 JS 日历库并关闭原生
type，统一走 JS 渲染
日期输入真正的坑不在“怎么让它出现”，而在“怎么确认它交上来的是人想填的、系统能信的”。兼容性只是表象，背后是浏览器能力碎片化和服务端信任边界的模糊。越早放弃“一次写完全平台可用”的幻想，越容易写出稳定代码。
