最直接且语义化的方式是使用，它在支持的浏览器中提供年份和周数选择控件，值格式为YYYY-Www；但Firefox和部分Safari不支持，会退化为文本框，需通过JavaScript或第三方库实现兼容性处理。
HTML中要设置表单的周选择，最直接且语义化的方式就是使用
。它提供了一个专门用于选择年份和周数的控件，通常会以一个日期选择器或下拉菜单的形式展现，让用户能直观地选取某年某周。解决方案
说实话，第一次接触到
input type="week"的时候，我心里是有点小激动的，因为它确实解决了我们传统上要用好几个下拉菜单或者复杂JavaScript库才能搞定的周选择问题。它的用法非常简单，直接在你的HTML表单里写上这一行：
这样，浏览器就会根据自身实现，弹出一个允许你选择年份和具体周数的界面。比如，在Chrome浏览器里，你会看到一个日历，但选择的单位是周，并且最终提交的值会是
YYYY-Www的格式，例如
2023-W35代表2023年的第35周。这省去了我们自己解析日期、计算周数的麻烦，简直是前端开发者的福音。
input type="week"
在不同浏览器中的表现一致吗？
这是一个非常现实的问题，也是我在实际项目中经常会遇到的“坑”。坦白讲，不一致。虽然HTML5规范定义了
input type="week"，但各大浏览器对其支持程度和表现形式却不尽相同。
立即学习“前端免费学习笔记（深入）”；
举个例子，Chrome、Edge、Opera这些基于Chromium的浏览器，对
type="week"的支持是比较好的，它们会提供一个直观的日历控件，你可以很方便地点击选择。但如果你在Firefox里打开同一个页面，你会发现
input type="week"压根就没有那个漂亮的周选择器，它会直接退化成一个普通的
input type="text"文本框。Safari浏览器在桌面端也类似，表现为文本框，但在iOS上则会弹出系统自带的滚轮选择器。
这意味着什么呢？这意味着如果你单纯依赖
input type="week"，你的用户体验可能会在不同浏览器之间产生巨大的差异。对于追求一致性用户体验的项目来说，这显然是不可接受的。所以，我们不能盲目地只用这一个标签，还得考虑它的兼容性问题，准备好备用方案。
如何为 input type="week"
添加默认值或设置选择范围？
虽然兼容性有点让人头疼，但
input type="week"还是提供了一些实用的属性来增强其功能，比如设置默认值、限制可选范围。
要设置一个默认值，你可以使用
value属性。记住，它的值必须是
YYYY-Www这种格式。比如说，你想默认选中2023年的第40周，可以这样写：
这个
value属性在所有支持
type="week"的浏览器中都会生效。如果浏览器不支持，它会作为文本框的默认值显示。
如果你想限制用户只能选择某个时间段内的周数，那么
min和
max属性就派上用场了。它们的格式也和
value一样：
通过
min和
max，你可以有效地引导用户进行符合业务逻辑的选择。比如，你只想让用户选择当前年度的周数，或者只允许选择未来几个月的周数，这都是非常实用的限制。当然，这些限制也只在支持
type="week的浏览器中才能生效，对于退化为文本框的浏览器，你需要通过JavaScript进行额外的校验。
当 input type="week"
不被支持时，我们有哪些替代方案？
既然我们知道
input type="week"的兼容性不是百分百完美，那么在它不被支持时，我们肯定不能让用户傻眼。这时候，一些备用方案就显得尤为重要了。
最常见的做法是，让它退化成一个普通的
input type="text"文本框，然后结合 JavaScript 库来实现周选择功能。这其实是一种“渐进增强”的思想：先用原生HTML提供基本功能，再用JavaScript增强用户体验。
你可以考虑引入一些成熟的日期选择库，比如：
- Flatpickr: 这是一个轻量级、高度可定制的日期时间选择器，它支持多种模式，包括周选择。你可以配置它只选择周，并自定义输出格式。
- jQuery UI Datepicker: 如果你的项目已经引入了jQuery，那么它的Datepicker插件也是一个不错的选择，通过一些配置也能实现周选择功能。
- 原生JavaScript实现: 当然，如果你对性能和库的依赖有严格要求，也可以自己用原生JavaScript写一个周选择器。这通常涉及到计算周数、构建日历视图等，工作量会大一些，但灵活性最高。
无论选择哪种库，核心思路都是一样的：当浏览器不支持
type="week"时，我们检测到这种情况，然后用JavaScript代码动态地将这个
input type="text"转换为一个功能完善的周选择器。这样，无论用户使用什么浏览器，都能获得相对一致且友好的体验。这种策略虽然会增加一点点前端代码量，但从用户体验和项目健壮性来看，绝对是值得的投入。
