根本原因是浏览器原生支持差异和系统级依赖：Chrome/Edge/新版Safari原生支持，Firefox需手动开启dom.forms.datetimepicker.enabled，iOS Safari则依赖系统语言与区域设置（如lang="zh-CN"且区域设为“中国”），并受CSS（appearance/pointer-events）和JS（disabled/readonly）限制。
为什么
根本原因不是代码写错了，而是浏览器原生支持差异和系统级依赖。Chrome、Edge、新版 Safari 原生支持 type="date" 并自动唤起日期选择器；但 Firefox 默认不启用（需手动开启 dom.forms.datetimepicker.enabled），iOS Safari 仅在部分版本中完整支持，且严重依赖系统语言/区域设置——比如系统设为中文简体时，某些旧版 iOS 会直接降级为文本输入框。
检查并强制触发原生日历的必要条件
光写 不够，必须满足以下全部条件：
- 页面
标签声明了正确的 lang 属性，例如（影响 iOS 行为） - 用户设备操作系统已启用日期选择器功能（iOS 设置 → 通用 → 语言与地区 → 区域必须是“中国”或“美国”等明确支持该控件的区域）
- 没有 CSS 强制覆盖
appearance: none或pointer-events: none，这两者会直接禁用原生交互 - 确保 input 没有被 JavaScript 动态设为
disabled或readonly（哪怕只在初始化瞬间）
Firefox 下启用日期选择器的实操步骤
Firefox 默认关闭该功能，需手动开启配置项：
- 地址栏输入
about:config，回车后确认风险提示 - 搜索
dom.forms.datetimepicker.enabled - 双击该项，将其值从
false改为true - 重启浏览器生效（无需改其他配置）
注意：这个开关仅对桌面版 Firefox 有效，Android/iOS 版 Firefox 不支持 type="date" 的原生日历，必须用 polyfill。
立即学习“前端免费学习笔记（深入）”；
当原生失效时，最小成本 fallback 方案
不要一上来就引入 fullcalendar 或 flatpickr 这类重型库。先判断是否真需要视觉定制：
- 如果只是想保证基础可用性，加一行 JS 检测即可：
if (!('showPicker' in HTMLInputElement.prototype)) { // 当前环境不支持原生日历，可加载轻量 polyfill 或改用 text + 正则校验 } - 推荐用 date-input-polyfill，仅 3KB，自动检测并补全
showPicker()方法，不影响原生逻辑 - 避免用
type="text"+ 自己写日历弹层——日期格式验证、时区处理、无障碍支持（ARIA）成本远高于引入一个 polyfill
真正容易被忽略的是：iOS 上即使原生日历能弹出，input.value 返回的永远是 YYYY-MM-DD 格式字符串，和用户看到的显示格式无关；任何依赖 toLocaleDateString() 渲染的逻辑，必须单独处理，不能假设输入框内显示的就是最终值。
