iOS Safari 禁止重置 input[type="date"] 样式，仅允许调整字体、颜色、对齐等文本属性；可靠方案是语义化模拟+原生控件兜底，并注意日期格式须为“YYYY/MM/DD”或纯“YYYY-MM-DD”字符串。
为什么 input[type="date"] 的样式重置在 iOS 上基本无效
iOS Safari 对 input[type="date"] 做了系统级锁定——不是你没写对，是 Apple 明确禁止 Web 页面接管其可访问性渲染逻辑。即使同时写了 -webkit-appearance: none 和 appearance: none，下拉箭头、灰底、圆角、文字颜色依然不可控；强行设置 background-color 或 border-radius 通常无反应，甚至导致点击失焦或软键盘不弹出。
input[type="date"] 能安全微调的仅限内部文本样式
iOS 不支持 ::-webkit-datetime-edit（该伪元素仅 Chrome / Android WebView 有效），但 Safari 允许有限干预文本层，前提是保留原生交互结构：
- 可用：修改字体大小、行高、文字颜色（
color）、文字对齐（text-align） - 可用但需谨慎：用
padding微调内边距（避免过小导致点击区域过窄） - 禁用：任何涉及
background、border、border-radius、cursor的尝试，大概率失效或触发降级 - 必须保留：原生
width和height行为，不要设为0或auto，否则可能被 Safari 隐藏
真正可靠的替代方案：语义化模拟 + 原生 fallback
放弃重置，改用可完全控制的 UI 模拟，同时保持原生控件作为无障碍和功能兜底：
- 用
<div role="combobox" aria-expanded="false"> 包裹自定义输入框 + 下拉面板 <li>隐藏原生 <code>input[type="date"]（position: absolute; opacity: 0; pointer-events: none;），但保留在 DOM 中并同步值 - 监听自定义面板的日期选择，同步写入原生
input的value和dispatchEvent(new Event('change', {bubbles: true})) - 必须支持键盘导航（
↑/↓/Enter）和屏幕阅读器读取，否则违反 WCAG
轻量级库如 flatpickr 默认启用这种模式，且已处理 Safari 的 focus/blur 边界问题，比手写更稳。
立即学习“前端免费学习笔记（深入）”；
容易被忽略的关键点
很多人以为加个 type="date" 就万事大吉，但实际线上最常出问题的不是样式，而是时间格式兼容性："2026-07-28" 在 iOS Safari 可解析，"2026/07/28" 才是跨平台最稳的字符串格式；若后端返回带时分秒的 ISO 字符串（如 "2026-07-28T08:24:00"），iOS 会直接拒绝解析——必须截断或转成纯日期字符串再赋值。
