应使用 change 事件配合初始值缓存与 ISO 格式校验来可靠检测日期变化；避免依赖 input 事件，因其在 Safari 等浏览器中对 date 类型基本无效，且方向键操作不触发；需结合 keydown 与光标位置判断字段修改意图。
如何用 change 事件可靠检测日期是否变化
原生 <input type="date"> 的 change 事件只在用户**完成选择并离开输入框（或确认日历）后触发**，且仅当 value 真正改变时才触发。这比 input 事件更干净，避免了无效中间状态干扰。
但要注意：浏览器对空值的处理很特殊——如果用户选了一个无效日期（如 2025-02-29），value 会直接变为空字符串 ""，此时 change 仍会触发，但前后值可能都是 ""，无法判断“是否修改”。所以不能只靠 === 比较。
- 必须在首次加载时缓存初始
value，比如从 DOM 属性或服务端注入的默认值读取 - 每次
change触发后，立即更新缓存值，供下一次比较使用 - 比较前先检查
value是否为有效 ISO 字符串（长度为 10 且匹配/^\d{4}-\d{2}-\d{2}$/），避免new Date("")返回Invalid Date
为什么不能只监听 input 事件
input 事件在用户键盘编辑时频繁触发，但对 type="date" 来说，**大多数现代浏览器（尤其是 Safari 和部分 iOS WebView）根本不允许键盘直接编辑文本内容**——它们只弹出原生日期选择器，input 事件几乎不会触发。即使在 Chrome/Firefox 中支持编辑，方向键（ArrowUp/ArrowDown）调整字段时也常不触发 input，而只触发 keydown。
更麻烦的是：当用户通过方向键把 2024-02-29 调成 2023-02-29，浏览器会清空 value，但这个过程没有 input 事件，只有 change 在最终提交时才发生。所以依赖 input 会漏掉关键变更。
立即学习“前端免费学习笔记（深入）”；
- Safari 中
input对type="date"基本不可用，属于伪需求 - 方向键操作不保证触发
input，但一定触发keydown和最终的change - 若真需实时响应（如禁用按钮），应结合
keydown+ 光标位置做意图预判，而非等待值落地
如何区分是年/月/日字段被修改导致清空
当 value 变成 ""，仅靠 change 事件无法知道是哪一部分改出问题。这时必须回溯操作意图，核心是监听 keydown 并检查 selectionStart 和 selectionEnd。
因为 type="date" 的标准格式是 YYYY-MM-DD（10 字符），各字段位置固定：
- 年份字段覆盖索引
0–3（如"2024"） - 月份字段覆盖索引
5–6（如"02"，注意中间的-占位） - 日期字段覆盖索引
8–9（如"29"）
只要在 keydown 中检测到 event.key 是 "ArrowUp" 或 "ArrowDown"，再看光标是否落在上述区间内，就能准确锁定用户正在调哪个字段。例如：光标在 8–9 区间按 ↑，大概率是 02-29 → 02-30 → 清空；若在 0–3 区间按 ↓，则是 2024 → 2023 → 02-29 失效。
这个逻辑在 Chrome/Firefox 中稳定有效，但在 Safari 中因不支持文本编辑，selectionStart 常为 null 或 0，需提前检测并降级为仅依赖 change 回滚策略。
容易被忽略的兼容性细节
最常被跳过的不是逻辑，而是初始化和边界值处理：
-
input.value初始可能是""、undefined，或带时区的非法字符串（如从表单重载时残留），不能直接传给new Date() - 某些旧版 Safari 对
new Date("2024-01-01")返回Invalid Date，安全写法是拆解split("-")后手动构造：new Date(year, month - 1, day) - 用户手动粘贴非标准格式（如
"01/01/2024"）时，浏览器会自动忽略或清空，但change不触发——这意味着你得额外监听paste并拦截 - 移动端软键盘唤起后，用户可能取消选择，此时
value不变，但change不触发，无需处理；但若你用了自定义浮层，则需监听blur配合防抖判断是否放弃
真正难的不是“怎么监听”，而是“怎么定义一次有效的修改”——它取决于你的业务场景：是只要用户点开日历就算？还是必须值落地？是否要捕获无效输入意图？这些决定了你得组合几个事件，而不是只绑一个 change。
