先记住这个答案
周输入的提交值是 YYYY-Www 形式，例如 2026-W01，不是某一天的日期。ISO 周从周一开始，包含当年第一个星期四的那一周是第一周，因此跨年时，周年份可能与某一天的公历年份不同。一年不固定只有 52 周，部分 ISO 周年份有第 53 周。处理排期时要用真正理解 ISO 周的日期逻辑，不能只拼字符串或假设每年周数相同。
- 值格式是年份加
W和两位周号 - ISO 周从周一开始
- 第一周包含该年第一个星期四
- 有些周年份存在第 53 周
跨年几天可能属于下一周年份
排班系统按周汇总时，十二月末的几天可能被算进下一周年份，元旦后的几天也可能仍属于上一周年份。week 的年份不是简单从所选周的周一日期取 getFullYear()。
<label for="sprint">迭代周</label>
<input id="sprint" name="sprint" type="week"
min="2026-W01" max="2026-W53" required>
<p>按 ISO 周编号选择排期。</p>控件提交的是周编号；2026 这个 ISO 周年份有第 53 周。换成年份后必须重新计算终点，不能把所有年份的 max 都固定写成 W52 或 W53。
周编号适合周报或迭代计划。如果业务实际需要一个明确的开始日期和结束日期，服务端应把周值按 ISO 规则换算为日期范围，并与用户时区和项目日历要求核对。
第一周不是一月一日那周的简单编号
ISO 规则用“包含当年第一个星期四的周”确定第一周，等价于新年至少有四天落在该周。周从周一开始，所以跨年边界不能用“1 月 1 日所在周永远是 W01”判断。
有些周年份会排出第 53 周。面试里说清规则比背哪年有 53 周更有用；业务代码应使用可靠的日期库或标准算法，不要按天数除以七向上取整。
ISO 周数有一个反直觉例子：2021 年 1 月 1 日属于 2020-W53，因为它所在那周的大部分日期在 2020 年。若把 YYYY-Www 中的年份当成公历日期年份，年末和年初报表就会归错组。后端若用数据库的周函数，还要确认它是否遵循同一套 ISO 周规则；仅把日期格式化成“年 + 第几周”并不可靠。控件不支持时可能回退为文本输入，服务器仍要检查周号是否真实存在。
容易答错的地方
- 认为
YYYY一定等于所选周每一天的公历年份 - 跨年周会同时覆盖两个公历年份；周年份由 ISO 第一周规则决定。
- 认为所有年份只有 52 周
- ISO 周年份可能有 53 周，范围校验必须按实际年份计算。
面试官还会怎么问？
ISO 周从周几开始？
周一开始，周日结束；这和某些地区日历界面以周日开头不同。
如何找某周对应的日期范围？
按 ISO 周年份先定位第一周的周一，再向后移动相应周数；不要直接解析 YYYY 当成周一所在年。
浏览器不支持原生周选择器怎么办？
保留可理解的格式说明与服务端校验，必要时提供自定义日期范围选择；不能只依赖控件外观。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。