原生 month 输入框在 chrome 中显示年月选择器，在 safari 中仅显示文本框且不触发 change 事件；week 输入框在所有主流浏览器中均无原生 ui，实际不可用；应统一降级为 type="text" 并通过 js 格式校验与服务端严格解析。
month 输入框在 Chrome 和 Safari 中的行为差异
原生 <input type="month"> 在不同浏览器中渲染效果不一致：Chrome 显示为带年月选择器的输入框，Safari 则只显示文本框（无下拉面板），且不触发 change 事件——这是实际开发中最常踩的坑。
原因在于 Safari 对 month 的支持停留在“表单提交时能正确解析值”，而非提供 UI 控件。若依赖用户点击选择，必须降级处理。
- 始终设置
value为YYYY-MM格式（如"2024-03"），否则 Safari 会清空或忽略 - 监听
input而非change，因为 Safari 在手动输入时不会触发change - 建议搭配
pattern="\d{4}-\d{2}"和title="格式：YYYY-MM"提示用户
week 输入框几乎无法直接使用
<input type="week"> 在所有主流浏览器中均无原生选择器 UI：Chrome 显示为文本框，Firefox/Safari 甚至不识别该类型、回退为 text。即使 value 设置为 "2024-W12"，也无法保证校验或交互一致性。
它不是“功能受限”，而是事实上的不可用。W3C 规范虽定义了格式（YYYY-Www），但实现层面基本缺席。
- 不要指望用户能靠肉眼输入合法 week 值——
"2024-W01"和"2024-W1"都可能被接受，但语义不同 - 服务端收到
week值后必须做严格正则校验：/^d{4}-Wd{2}$/，并验证周数是否在 01–53 范围内 - 如需真实 week 选择，应改用日历控件 + 周范围高亮（例如用 Flatpickr 或自定义逻辑计算 ISO 周）
如何安全地 fallback 到文本输入 + 格式校验
当原生控件不可靠时，最务实的做法是统一降级为 type="text"，再通过 JS 强制格式和行为。
- 对 month：监听
input，实时修正输入为YYYY-MM，例如用户输"2024/3"自动转成"2024-03" - 对 week：用正则
/^d{4}-Wd{2}$/匹配，输入中途可允许"2024-W"，但失焦时必须补全两位周数（如"2024-W5"→"2024-W05"） - 禁用移动端软键盘数字模式（
inputmode="numeric"会干扰日期分隔符输入），改用inputmode="text"
服务端接收时必须重新解析，不能信任前端 value
浏览器提交的 month 或 week 值看似标准，但实测中仍可能出现 "2024-03"（月）、"2024-3"（非法）、"2024-W00"（无效周）等变体。前端校验只是体验优化，服务端才是防线。
- PHP 示例：
DateTime::createFromFormat('Y-m', $_POST['month'])比直接new DateTime($_POST['month'])更安全 - Node.js 示例：用
date-fns的parseISO不适用 week，需手写解析逻辑，例如parseWeek("2024-W12")返回该周周一日期 - 特别注意时区：
month值无时间部分，但服务端解析时若用new Date("2024-03")会隐式转成本地时区，导致跨时区偏差
week 的 ISO 周计算逻辑复杂，别图省事用字符串拼接——哪怕只用一次，也应调用标准库（如 Python 的 datetime.strptime("2024-W12-1", "%Y-W%W-%w")）。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
