HTML5 仅支持公历，不处理农历闰月；2024-02-29 被接受是因公历闰年规则，非闰月支持；需用JS库实现农历及闰月功能。
HTML5 <input type="date"> 本身不处理闰月，只遵循公历（格里高利历）
HTML5 的 <input type="date"> 是纯公历控件，不支持农历、闰月、节气等中国传统历法概念。所谓“闰月”，是农历（阴阳合历）为协调朔望月与回归年而设置的额外月份（如“闰四月”），而浏览器原生日期控件底层调用的是操作系统级的公历日期 API（如 ICU 库），完全不感知农历规则。
输入值 2024-02-29 能被接受，是因为它是有效公历日期
2024 年是公历闰年，2 月有 29 日，所以 <input type="date" value="2024-02-29"> 会被正常渲染和提交。这不是“支持闰月”，而是标准闰年规则（能被 4 整除且不能被 100 整除，或能被 400 整除）的自然体现。浏览器不会校验你输的是不是“农历闰月”，它只按 ISO 8601 格式解析 YYYY-MM-DD 字符串，并验证其是否构成合法公历日期。
想处理农历闰月？必须脱离原生 type="date"，用 JS + 第三方库
若业务真需选择“农历日期”或识别“闰月”，比如选“甲辰年闰二月十五”，你需要：
- 禁用原生
<input type="date">，改用普通<input type="text">或自定义下拉/日历组件 - 引入支持农历的 JS 库，例如
lunar-javascript（轻量）、chinese-lunar-calendar或moment-chinese-calendar（已停止维护，慎用） - 自行实现农历年份→公历日期的双向转换，并在 UI 层标注“闰月”标识（如在月份旁加「闰」字）
- 注意：所有转换结果都依赖算法模型，不同库对历史农历（尤其是清以前）的推算可能有差异
服务端收到 2024-02-29 后，别误以为它对应农历闰月
后端接收到的始终是 ISO 公历字符串。如果你看到某天恰好落在农历闰月区间（例如 2025 年公历 3 月 29 日～4 月 26 日对应农历闰二月），那只是时间重叠，不是格式自带能力。要映射到农历，仍需在服务端调用相同农历库做转换——前后端农历逻辑必须一致，否则会出现“用户选了闰二月，后端解析成三月”的错位。
立即学习“前端免费学习笔记（深入）”；
真正容易被忽略的点是：闰月没有独立的 ISO 表示法，也没有 HTML 标准字段支持；所有“闰月交互”都是应用层模拟，且需全程控制时区（建议统一用 UTC+8 处理农历，避免夏令时干扰）。
