兼容性差，safari 直至 macos 14/ios 16 才支持，旧版降级为无校验文本框；value 返回 "yyyy-mm" 字符串，valueasdate 在旧 safari 中不可靠；需用 js 检测兼容性、手动格式化输入并兜底校验。
<input type="month"> 能用，但别指望它在所有浏览器里都正常工作——Safari 一直到 macOS 14 / iOS 16 才支持，旧版直接降级为普通文本框，且不带任何校验或日期逻辑。
为什么 type="month" 在 Safari 里不显示选择器
这是最常被卡住的点：Safari 直到 2023 年才实现该规范，且仅限较新系统。用户看到的是一个空文本框，输入格式也无提示（如“YYYY-MM”），连 placeholder 都不会自动补全。更麻烦的是，value 返回的字符串始终是 "YYYY-MM" 格式，但 Safari 旧版本返回空字符串或原始输入值，导致 JS 取值不可靠。
- 检查兼容性：用
document.createElement("input").type = "month"测试是否被识别，再读取input.type看是否仍为"month" - 不要依赖
min/max属性做校验——Safari 忽略它们，Chrome/Firefox 则会禁用超出范围的月份 - 如果必须支持旧 Safari，得用 JS 模拟下拉或引入轻量级月选择器库（如 flatpickr 的 month-only 模式）
value 和 valueAsDate 的行为差异
value 总是返回标准格式字符串（如 "2023-12"），而 valueAsDate 在 Chrome/Firefox 中返回一个 Date 对象（日期固定为当月 1 日、时区本地时间），但在 Safari 旧版本中返回 null 或抛错。这意味着不能直接对 valueAsDate 调用 .getFullYear() 等方法而不加判断。
- 安全读取月份：优先用
input.value，再用input.value.split("-")解构年月 - 避免
new Date(input.value)：部分浏览器会把"2023-12"解析为 UTC 时间，导致本地时区显示成次年 1 月 1 日 - 设置值时，只写
input.value = "2023-12"，不要试图赋Date对象给valueAsDate（兼容性差）
移动端键盘与体验陷阱
Android Chrome 会弹出原生月选择器，但 iOS Safari（即使新版）仍只弹出数字键盘——用户得手动输入 "2023-12"，极易输错格式。没有视觉反馈，也没有自动补零（输 "2023-1" 不会变成 "2023-01"）。
- 必须加
pattern="\d{4}-\d{2}"和title="格式：YYYY-MM"提示用户 - 监听
input事件做实时格式修正：检测输入长度、插入短横线、补零（但注意不要干扰用户编辑中间位置） - 禁用
autocomplete="off"没用；iOS 会忽略它，仍可能填入错误的完整日期
真正难的不是写这个标签，而是处理它在不同环境里“看似存在、实则失效”的状态——尤其是当后端只认 YYYY-MM 字符串时，前端却要为 Safari 用户兜底输入、校验和展示逻辑。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
