原生 与自定义日历非替代关系，而是协同关系：前者保障可访问性、表单验证和系统级交互，后者仅在需动态禁用、多日期范围、非单日粒度等原生无法满足时作为ui增强层，须通过隐藏原生input或同步value来保持表单规范。
HTML <input type="date"> 和自定义日历组件不是替代关系
浏览器原生的 <input type="date"> 是一个受控的日期选择器，它不暴露 DOM 日历面板，也不允许样式定制或逻辑干预；所谓“HTML 日历”（比如用 <table> + JS 拼出来的月份视图）本质是独立实现的 UI 组件，和原生 input 无继承或替换关系。强行用 div 日历“替代”原生 input，反而会破坏表单可访问性、键盘导航和移动端软键盘唤起逻辑。
<ul>
<li>原生 <code>type="date" 在 iOS Safari 和 Android Chrome 中自动唤起系统日期滚轮，自定义日历无法触发该行为
<input type="date"> 为日期控件，而 <div class="calendar"> 需手动加 <code>role="application"、aria-label 等才能勉强模拟
"2024-05-20"）时，原生 input 自动解析并校验格式；自定义日历需自己监听 paste、正则匹配、再同步到隐藏 input 或状态变量什么时候必须用自定义日历而不是 <input type="date">
只有当业务需求突破了原生控件的能力边界时，才值得引入自定义日历。典型场景包括：
- 需要高亮多个可选日期范围（如酒店预订中“入住/离店”双日期+中间可用天数）
- 禁用动态日期（如“仅开放未来 14 天且避开节假日”，而节假日数据来自 API）
- 支持周选择、月选择、季度选择等非单日粒度操作
- 与已有设计系统强绑定，要求日历样式完全一致（原生控件在各浏览器中外观差异大，且无法用 CSS 修改内部结构）
注意：<input type="date"> 不支持设置最小/最大日期以外的禁用逻辑——它的 min/max 只接受静态 ISO 字符串，无法响应式更新或叠加条件。
自定义日历如何与表单正确集成
关键不是“替代”，而是“协同”。自定义日历应作为 UI 层，背后仍需一个符合表单规范的受控输入源：
- 始终保留一个
<input type="hidden" name="booking_date">或受控的<input type="text" hidden>，值为 ISO 格式（如"2024-05-20"），供后端接收和表单提交 - 不要移除原生
type="date"，而是用display: none隐藏它，并用 JS 同步日历点击结果到它的value属性——这样保持了表单验证（required、validity.valid）、reset 行为和无障碍基础 - 若必须禁用原生唤起（例如防止用户绕过日历直接输错格式），可加
readonly并监听focus后立即blur()，但需确保键盘用户仍能用Tab进入、用方向键操作日历
示例同步逻辑：
calendar.onDateSelect = (date) => {<br> const iso = date.toISOString().split('T')[0]; // 保证 YYYY-MM-DD<br> nativeInput.value = iso;<br> nativeInput.dispatchEvent(new Event('change', { bubbles: true }));<br>};
移动端适配中最容易被忽略的兼容点
自定义日历在桌面端表现稳定，但在 iOS 和部分安卓 WebView 中，几个底层限制常被忽视：
- iOS Safari 对
position: fixed在滚动中的定位有渲染 bug，日历弹层若设为fixed，快速滚动后可能错位——改用absolute+ 动态计算top/left更可靠 - 安卓 WebView（尤其旧版）不支持
Intl.DateTimeFormat的month: "short"等选项，导致月份名显示为英文缩写失败，需 fallback 到数组映射 - 触摸事件中，
touchstart+touchend响应延迟高于click，但click在 iOS 上有 300ms 延迟；建议用pointerdown+pointerup，并加touch-action: manipulation减少延迟
真正难的不是画出格子，而是让每个格子在各种设备上都可聚焦、可读取、可提交、可重置——这些细节决定了它是“能用”，还是“敢用”。
