HTML5 需用 YYYY-MM-DD 格式，Safari 14.1+ 才支持，旧版 iOS Safari 降级为文本框；检测支持性应使用 document.createElement("input").type === "date"，不支持时改 type="text" 并用正则校验；React 中优先用 value 而非 defaultValue，服务端日期需截取前10位；样式定制需避免禁用点击唤起功能。
date input 的基本写法和浏览器兼容性
HTML5 原生 <input type="date"> 能直接唤起系统级日期选择器，但不是所有浏览器都支持——Safari 14.1+ 才开始支持，旧版 iOS Safari 完全不识别，会退化为普通文本框。
常见错误现象：type="date" 在部分安卓 WebView 或微信内置浏览器里显示为空白或无响应；用户手动输入格式（如2023-1-1）被拒绝，但没提示原因。
- 必须用
YYYY-MM-DD格式传值，哪怕页面显示是“2023年1月1日”，input.value永远是字符串"2023-01-01" - 不支持设置中文占位符（
placeholder对type="date"无效），别白费劲加 - 移动端测试务必覆盖 iOS Safari 和主流安卓 WebView（比如微信、QQ 内置浏览器），不能只看 Chrome
如何让 date input 在不支持的浏览器里降级为文本框 + 校验
靠 CSS 或 JS 检测 input.type === "date" 是否生效，比 UA 判断更可靠。检测失败就手动改成 type="text"，并绑定日期格式校验逻辑。
使用场景：需要统一表单交互体验，又不能强制用户升级浏览器。
立即学习“前端免费学习笔记（深入）”；
- 用
document.createElement("input").type = "date"测试支持性，返回"date"才可用原生控件 - 降级后，用正则
/^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$/校验输入，注意月份和日期要带前导零 - 别依赖
input.checkValidity()降级后的校验结果，它对type="text"不检查日期逻辑，得自己补
value 属性和 defaultValue 的区别与陷阱
value 是受控组件的关键，而 defaultValue 只在首次渲染时生效，后续改了没用。React 项目里尤其容易踩坑。
常见错误现象：初始设了 defaultValue="2023-01-01"，用户选了新日期，再点重置按钮，日期没回到初始值。
- 服务端返回的日期字段（如
"2023-01-01T00:00:00Z"）必须先截取前10位转成"2023-01-01"才能赋给value，否则控件不显示 - JS 动态设置时，用
input.value = new Date().toISOString().slice(0, 10)最稳妥，避免时区导致错一天 - 如果用
useState管理日期，初始化状态别写new Date()，直接写字符串"2023-01-01"，省去格式转换
样式定制和 focus 状态下的行为异常
原生 date input 的内部 UI 无法用 CSS 完全重写，但可以隐藏默认箭头、调整字体、控制 focus 时的 outline。不过某些样式操作会意外禁用点击唤起日历的功能。
性能影响不大，但兼容性和交互逻辑容易出问题。
- 用
::-webkit-calendar-picker-indicator隐藏 Chrome/Edge 的小箭头，但加display: none后，iOS Safari 可能完全点不动 —— 改用opacity: 0; pointer-events: none;更安全 - 给
input:focus加outline: none时，务必补上其他视觉反馈（比如边框变色），否则可访问性不达标 - 不要给 date input 包一层
<label></label>并设置for，部分安卓浏览器会触发两次点击事件
最麻烦的是跨浏览器日期解析：不同系统对 "2023-1-1" 这种非标准格式的容忍度不同，有的报错，有的静默修正。只要涉及用户手动输入，就得在提交前做一次格式归一化，别信浏览器自动帮你兜底。
