input type="month" 的值是 YYYY-MM 格式字符串（如"2024-03"），需手动补日（如"-01"）并用 new Date(year, month-1, 1) 转为 Date 对象，避免直接 new Date(value) 导致 Invalid Date。
input type="month" 的值到底是什么格式
它返回的是 YYYY-MM 格式的字符串（例如 "2024-03"），不是 Date 对象，也不是时间戳，更不是本地化后的显示文本。浏览器原生控件只负责输入和校验这个格式，不提供解析逻辑。
常见错误是直接用 new Date(input.value) 试图转成日期对象——这在多数浏览器里会得到一个无效日期（Invalid Date），因为 Date 构造函数无法正确解析只有年月的字符串。
- 必须手动补全日部分（如拼成
"2024-03-01"）才能被Date正确识别 - 注意时区影响：补
-01后解析出的Date对象默认是本地时区的 0 点，不是 UTC - 如果后端需要 ISO 格式或时间戳，得自己处理时区对齐，不能依赖浏览器自动转换
如何安全地把 month input 转成 JavaScript Date 对象
最稳妥的方式是显式补日并用 new Date() 构造，而不是依赖隐式解析：
const monthInput = document.querySelector('input[type="month"]');
const value = monthInput.value; // "2024-03"
if (value) {
const [year, month] = value.split('-');
const date = new Date(year, month - 1, 1); // 注意 month 是 0-indexed
}别用 new Date(value)，IE 和旧版 Safari 会失败；也别用 Date.parse()，它行为不一致且返回毫秒数，容易误判。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
month - 1是关键：HTML 的YYYY-MM中月份是 1~12，而Date构造函数要求 0~11 - 构造出的
date表示该月第一天的本地时间（如北京时间 2024-03-01 00:00:00） - 如果需 UTC 时间，用
Date.UTC(year, month - 1, 1)再传给new Date()
和服务端交互时要注意的兼容性问题
后端通常期望完整日期（YYYY-MM-DD）或时间戳，但 input[type="month"] 只发 YYYY-MM。若直接提交表单，多数框架（如 Express、Django）会收到不完整的日期字符串，可能解析失败或默认补 01 日但不声明时区。
- 前端提交前务必标准化：补
-01或转成时间戳，再通过FormData或 JSON 显式传值 - 不要依赖浏览器自动填充隐藏字段——不同浏览器对空值或非法值的处理不一致（比如清空后
value是空字符串还是保持上次值） - 移动端 iOS 的 month picker 在某些版本中会返回带时区的字符串（如
"2024-03Z"），需正则清洗
为什么不用 moment.js 或 dayjs 直接 parse("2024-03")
dayjs("2024-03") 默认会 fallback 成当前日（比如今天是 5 号，就变成 2024-03-05），moment("2024-03", "YYYY-MM") 需显式指定格式且仍可能因 locale 设置产生偏差。它们都掩盖了“月份本身无日”的语义问题。
真正需要的是明确语义：你选的是“2024 年 3 月”，不是“2024 年 3 月某天”。所以业务逻辑里应优先用字符串比较（value >= "2024-03"），而非转 Date 后比时间戳。
- 字符串比较天然支持年月范围判断，且无时区干扰
- 只有当要计算该月天数、获取首尾日、或与含日的日期运算时，才转 Date
- 转之前确认是否真需要——很多场景下存
"2024-03"比存1709222400000更清晰、更易调试
实际用的时候，先想清楚你要拿这个月做什么：查数据库范围？算天数？还是仅作标识？不同目的，解析路径完全不同。
