HTML input type="week" 默认值必须为 ISO 8601 周格式（如"2024-W23"），周数需两位且真实存在；JS 设置需手动计算ISO周，不支持placeholder；后端解析须用%G-%V而非%Y。
HTML input type="week" 的默认值必须符合 ISO 8601 格式
浏览器只接受形如 "2024-W23"（年-周）的字符串作为 value，任何其他格式（比如 "2024-06-10"、"2024/06/10" 或空字符串 ""）都会导致默认值失效，输入框显示为空或回退到当前周。
注意：周数必须是两位数字（如 W01，不是 W1），且该周在对应年份中真实存在（例如 2024-W54 无效，因 2024 年只有 52 周）。
- ✅ 正确：
<input type="week" value="2024-W23"> - ❌ 无效：
<input type="week" value="2024-06-10">（会被忽略） - ❌ 无效：
<input type="week" value="">（不等于“清空”，而是未设置默认值）
用 JavaScript 动态设置 input[type=week] 的默认值要先格式化
直接赋值 new Date() 或 toISOString() 没用——它们返回日期字符串，不是周格式。必须手动计算年份和 ISO 周数。
关键点：JavaScript 原生不提供 getWeek()，需自行实现或借助 toLocaleString('en', { week: 'numeric' })（但兼容性有限），更稳妥的是用简单算法推算。
立即学习“前端免费学习笔记（深入）”；
- 推荐轻量逻辑：取周一为每周起点，用
date.getTime() + (1 - date.getDay()) * 864e5对齐周一，再计算 ISO 年与周 - 常见错误：用
getMonth() + 1或getDate()拼接，结果不是周标识 - 示例（获取本周默认值）：
function getISOWeek(date) { const d = new Date(date); d.setUTCDate(d.getUTCDate() + 4 - (d.getUTCDay() || 7)); const yearStart = new Date(d.getUTCFullYear(), 0, 1); return `${d.getUTCFullYear()}-W${Math.ceil(((d - yearStart) / 864e5 + 1) / 7).toString().padStart(2, '0')}`; } document.querySelector('input[type=week]').value = getISOWeek(new Date());
设置默认值后用户仍可能看到“无值”或 placeholder 行为异常
部分浏览器（尤其是 Safari 和旧版 Edge）对 input[type=week] 的渲染不一致：即使 value 合法，初始时也可能不显示周信息，或点击后才刷新。这不是 bug，而是控件生命周期问题。
- 不要依赖
placeholder属性——input type="week"不支持它，设了也无效 - 避免在 DOM 尚未就绪时设置
value，否则 Safari 可能忽略（建议用DOMContentLoaded或setTimeout(..., 0)延迟赋值） - 如果用框架（如 Vue/React），确保绑定的响应式值是字符串类型，而非 Date 对象或数字
服务端接收时要注意周格式解析容易出错
表单提交后，后端收到的是类似 "2024-W23" 的字符串，不是时间戳。很多后端库（如 Python 的 datetime.strptime、Node.js 的 date-fns）需要显式指定 ISO 周解析模式，否则会报错或误解析为 1 月。
- Python 示例：
datetime.strptime("2024-W23", "%G-W%V")（%G是 ISO 年，%V是 ISO 周） - Node.js（date-fns）：
parseISO("2024-W23")❌ 不支持；要用addWeeks(startOfYear(new Date()), 22)手动算起始日 - 常见翻车点：用
%Y替代%G，会导致跨年周（如 2024-W01 实际属于 2023 年末）解析错误
周选择器看着简单，但格式链（HTML → JS → HTTP → 后端）上每一环都卡在 ISO 周定义的细节里。漏掉一个 W、少补一位、混淆 %Y 和 %G，值就无声消失了。
