input type="month" 是唯一原生支持年月选择的 HTML5 方式，值格式为 YYYY-MM 字符串，需严格补零且不含日，跨浏览器兼容性有限，老浏览器需降级为 text + pattern 校验。
input type="month" 是唯一原生支持年月选择的 HTML5 方式
HTML5 本身没有“格式化显示年月”的独立属性，input 元素通过 type="month" 原生提供年月选择界面和值格式（如 "2024-07"），这是浏览器直接支持、无需 JS 拼接的最简方案。
常见误区是试图用 type="date" + pattern 或 min/max 限制来模拟年月——这无法阻止用户选择具体日期，也不能保证提交值只含年月。
-
type="month"在 Chrome、Edge、Safari（≥15.4）、Firefox（≥57）中可用；iOS Safari 支持但 UI 显示为年+月滚轮 - 提交值固定为
YYYY-MM格式字符串（如"2024-07"），不带日，符合后端常见解析预期 - 不支持设置默认“仅年月”的 placeholder，placeholder 属性在该类型下被忽略
value 属性必须是 YYYY-MM 格式，否则输入框为空或回退为无效状态
value 写错格式会导致浏览器不渲染默认值，甚至在部分版本中触发 ValidityState.badInput === true。不是“自动截取”或“容错填充”。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- ✅ 正确：
<input type="month" value="2024-07"> - ❌ 错误：
value="2024/07"、value="2024-7"（月份未补零）、value="2024-07-15"（含日） - 动态设置时需手动格式化：JavaScript 中用
String(date.getFullYear()) + "-" + String(date.getMonth() + 1).padStart(2, "0")
获取和提交的值始终是字符串，后端需按 YYYY-MM 解析
无论用户怎么选，input.value 返回的永远是类似 "2024-07" 的字符串，不是 Date 对象，也不带时区信息。这点常被前端忽略，导致用 new Date(input.value) 得到错误时间（如变成当月 1 日 00:00 UTC）。
立即学习“前端免费学习笔记（深入）”；
- 前端若需转为日期对象，应显式补日：例如
new Date(input.value + "-01") - 后端接收时不要依赖自动类型转换，直接按
YYYY-MM切分解析，避免因语言差异（如 Python 的datetime.fromisoformat()不支持纯年月）出错 - 表单提交时，该字段值以原始字符串发送，无额外编码或格式修饰
不支持 type="month" 的老浏览器只能降级为文本输入 + 正则约束
IE 完全不支持，旧版 Android WebView 也常失效。降级方案不是“加 polyfill”，而是务实处理：用 type="text" + pattern="\d{4}-\d{2}" + inputmode="numeric"，并辅以 JS 校验。
- pattern 只影响表单校验，不阻止用户输入；需监听
input事件实时过滤非数字和横杠 - 建议加
maxlength="7"限制长度，防止输长 - 注意移动端软键盘：
inputmode="numeric"在多数安卓机上会唤出数字键盘，但 iOS 需配合pattern="[0-9]*"才更可靠
"2024-7"），前端直接赋值就导致 input 空白；又或者在表单 reset 后未重置 value，造成状态残留。这些细节比语法本身更影响交付稳定性。 
