今天是第几周 · 本周是 2026 年第几周

在线查今天是第几周：打开就是本周是2026年第几周的大数字，下面写清本周从哪天到哪天、今天是本周第几天、今年一共 52 还是 53 周。本周是第几周、现在是第几周、这周是第几周、今天第几周、今天是多少周，问的都是同一件事；搜「今天是第几周2026年」这种带年份的写法，也能在年份下拉里翻过去。三种口径随手切：国际标准 ISO 8601、周日为第一天、自己填起点的教学周，全年周历表与两个反向查询都跟着变。

怎么用

一、进来就是答案

打开页面，最上面那个大号的「第 N 周」就是答案，不用点任何按钮。下面那一行小字把话说全：今年一共多少周、本周从哪天到哪天、今天是本周第几天。

页面上的日期按你这台设备的当天日期算，过了零点会自己换，不用刷新。所以不管你搜的是「今天是第几周」「本周是第几周」「现在是第几周」还是「这周是第几周」，看的都是同一个数字，只是问法不同。

二、三种口径，先选对再看数

大数字下面那一排按钮是这一页最要紧的地方。周次这件事没有唯一答案，取决于按谁的规矩数：

• 国际标准 ISO 8601（默认）：周一是一周的第一天；含有当年第一个星期四的那一周是第 1 周，等价的说法是「含 1 月 4 日的那一周」。这是编程、排产、跨国协作里最通行的口径，我国国家标准 GB/T 7408 的日期时间表示法与它一致（以标准原文为准）。
• 周日为第一天、1 月 1 日算第 1 周：北美的日历和不少表格软件的默认排法。它的特点是第 1 周和最后一周常常不满七天——1 月 1 日是星期六的年份，第 1 周就只有这一天。
• 自定义起点：填一个「第 1 周的周一是哪天」，从那天起每七天算一周。学校的教学周、团队的迭代周、排班表的周次都属于这一类。学生查「这周是第几周」，八成要的其实是这个。

三种口径一切，首屏大数字、全年周历表、下面两个查询会同时跟着变。你选的那一种记在本机，下次打开还是它。

三、全年周历表

工具条上能翻年份，从 1900 一直到 2100，翻远了点「回到今年」就回来。表里一周一行，给出周次、这一周的起止日期、这一周有几天、要不要跨月；本周那一行高亮，已经过去的周淡下去，一眼看得出今年走到哪儿了。

表里的「备注」列会标出三类值得注意的行：不满七天的头尾周、跨月的周，以及起止日期落在别的年份里的那几周。点表里任意一行，下面的「第 N 周是哪几天」会直接填好并给出这一周的完整日期。

窄屏上表格会自动收窄，备注列先让位，剩下四列排得下，不用横向拖。

四、两个反过来的查询

这两个查询是一对：

• 某天是第几周：选一个日期，给出它属于哪一年第几周、是这一周的第几天、这一周从哪天到哪天。年初年末的日子如果按 ISO 8601 归到了隔壁那一年，这里会明说。
• 第 N 周是哪几天：填一个周次，给出这一周的起止日期和各自是星期几。填了这一年没有的周次（比如 52 周的年份填 53），页面会直接告诉你这一年只有多少周，而不是随便给一个日期。

查完之后，年份会自动跟着跳到查询命中的那一年，周历表也一起翻过去，省得再手动找。

五、把周历带走

点「复制周历」，整年的周次和起止日期会整理成一段纯文本，一行一周，贴进聊天窗口、表格或者备忘录都不用再排版；开头那一行写明是按哪种口径算的、全年多少周，将来回头看不至于弄混。

浏览器不允许网页直接写剪贴板时，内容会自动放进页面底下的框里并选中，按 Ctrl+C（Mac 上是 ⌘+C）即可。这一页不需要联网，也不用登录和注册，打开就能用。

怎么看结果

「今天是第几周」得先问「按谁的规矩数」

这是最容易踩的坑：两个人拿着两个不同的数字，谁也没算错。差异来自两件事——一周从星期几开始，以及第 1 周怎么定。

按 ISO 8601，一周从周一开始，第 1 周必须至少有四天落在这一年里（等价说法是含第一个星期四、或者含 1 月 4 日）；按周日开头那种口径，一周从周日开始，1 月 1 日在哪一周，哪一周就是第 1 周，哪怕那一周只有一天。于是在年初，两种口径给出的数字可能整整差一周；一路数到年底，差距通常还在。

所以看到别处给的周次和这里对不上，别急着怀疑哪边错了，先把口径切到对应的那一种再比。同一天在三种口径下的周次都不一样，是正常的。

本周是第几周：那一行小字里的四个数

首屏那一行小字看起来短，其实回答了四个问题：

1. 今年一共多少周——52 或者 53（周日开头口径下还可能出现 54）。知道总数，才知道现在走到全年的哪个位置。
2. 本周从哪天到哪天——排会、约人、定截止日的时候，需要的往往是这两个日期，而不是那个周次。
3. 今天是本周第几天——周一是第 1 天还是第 2 天，恰好取决于你选的口径，这个数能帮你确认口径有没有选错。
4. 这一周归哪一年——只在 ISO 8601 口径下才会单独提示，见下一节。

年头年尾那几天为什么会「串门」

ISO 8601 有一条很硬的规矩：一周七天不许被年份切开，要么整周归这一年，要么整周归隔壁那一年，归谁看这一周的星期四落在哪年。

后果就是：1 月头上最多三天可能被划进上一年的最后一周，12 月末尾最多三天可能被划进下一年的第 1 周。页面遇到这种日子会专门加一行提示，把「日期写在哪一年、周次归哪一年」分开讲清楚。

这几天最容易出账：周报按周次归档、生产按周次排产的时候，年末那一周如果按日历年份归档，整周的数据就会被拆成两半。正确的做法是记「哪一年第几周」这一对，而不是只记周次。

今年是 52 周还是 53 周

按 ISO 8601，一个年份只会是 52 周或 53 周，没有第三种可能。判断规则只有一句：1 月 1 日是星期四，或者是闰年且 1 月 1 日是星期三，这一年就是 53 周。

原因很直白：平年 365 天＝52 周零 1 天，闰年 366 天＝52 周零 2 天。每过一年，年初那个「起点星期几」就往后挪一到两天，挪着挪着零头攒够了七天，就必须补出一整周来。页面上的常识卡会算出当前年份的周数，并列出往后最近的几个 53 周年份。

53 周的年份值得单独留意：按周付薪、按周排班、按周做同比的表，那一年会莫名其妙多出一格，不提前留位置，年底一定要返工。

教学周对不上，多半是起点差了一天

学校的「第几教学周」和日历上的周数是两回事。它由教务定，通常从开学那一周的周一起算，寒暑假可能连着数、也可能重新数。

所以在这一页要查教学周，只有一种正确用法：切到「自定义起点」，把课表上写明的第 1 周的周一填进去。起点差一天，后面每一周都会差一周——这是对不上号的头号原因。如果起点还没到，页面不会硬给一个数字，而是直接说「第 1 周还没开始」，并告诉你还差几天。

常见问题

今天是今年的第几周，和今天是第几周有区别吗？

同一件事的两种问法，答案是同一个数。要说有区别，「今年的第几周」多了一层暗示：这个数是相对某一年来数的。在 ISO 8601 口径下这层暗示很要紧——年初年末那几天，「今天所在的周」归的那一年，可能不是今天日期上写的那一年，页面会单独提示这种情况。

手机日历、办公软件里的周数和这里对不上？

先看口径。手机系统日历里的周数显示通常跟着系统「一周从星期几开始」的设置走，改成周日开头之后周数也会跟着变；办公软件里的周数则取决于用了哪个函数、填了什么参数。把本页口径切到对应的那一种，再核对同一天，一般就对上了。还是对不上的话，看看那边是不是采用了「1 月 1 日永远算第 1 周的第一天」这种更少见的数法。

为什么不按「1 月 1 日永远是第 1 周的第一天」来数？

这种数法确实存在，简单直白，但代价是一周的起点每年都在变：今年的「第 1 周第 1 天」是星期二，明年就成了星期三。这样一来「周」不再和星期对齐，跨年比较就没法比了——同样是第 20 周，今年是周二到周一，明年是周三到周二。ISO 8601 宁可牺牲年头年尾那几天的归属，也要保证每一周都是周一到周日，图的就是跨年可比。

能查很早以前或者很久以后的年份吗？

年份下拉从 1900 到 2100，这一段里的任何一天都能算。周数是纯粹的推算，不依赖任何数据源，也不需要联网，所以不存在「这一年还没公布」的问题。再往前推的年份涉及不同国家改用格里高利历的时间不一致，本页不做，免得给一个看着整齐、实际不成立的答案。

一年最多有几周？会不会出现第 54 周？

按 ISO 8601，最多 53 周，不会有第 54 周。但在「周日为第一天、1 月 1 日算第 1 周」那种口径下，1 月 1 日是星期六的闰年会出现第 54 周——因为头尾各有一个只有一两天的残周，把中间 52 个整周挤开了。这不是算错，是那种口径本身允许残周存在。页面在表里会把这些不满七天的周标出来。

这一页和日历、日期计算器、工作日计算器怎么分工？

全年日历把十二个月摊成一屏，带放假调休和农历，适合看一整年的全貌；日期计算器算两个日期相差多少、往后推多少天是哪天；工作日计算器扣掉法定节假日算区间里有几个工作日；今天是什么日子回答今天的农历、节日与纪念日。本页只做周次这一件事，做深：三种口径、全年周历、正反两个查询。

原理与冷知识

「第几周」不是日历自带的属性，而是一套人为规定。年、月、日都有天文对应物：地球绕太阳一圈是年，月相一轮是月，自转一圈是日。唯独「周」没有——七天一循环是纯粹的社会约定，古老、稳固，却和年月完全不通约。365 除以 7 除不尽，于是「今年第几周」这个问题必然需要一条人定的规则来补口，而不同的人补出了不同的规则。你看到的所有周数分歧，根子都在这里。

ISO 8601 用「星期四」来断案，是一个很聪明的取巧。要判断一周归哪一年，最自然的想法是「看这一周里哪一年的天数多」。而一周七天里，第四天正好是多数天所在的那一侧——如果星期四落在某一年，那这一周至少有四天在这一年。于是「看星期四」和「看多数天」完全等价，却只要判断一天，不用数七天。这条规则还有两个等价说法：第 1 周是含 1 月 4 日的那一周，也是这一年的第一个完整周（从周一算起）。国际标准化组织在 1988 年首次发布 ISO 8601，此后多次修订，周编号这条规则一直没变。

为什么周数最多到 53，不会是 54。ISO 年从某个周一开始、到某个周日结束，长度必然是 7 的倍数，而它要覆盖的日历年是 365 或 366 天，所以只能取 364（52 周）或 371（53 周）——再多一周就是 378 天，比日历年多出十几天，第 1 周的四天规则会被破坏。反过来，周日开头那种口径允许残周，所以 54 周是可能的，代价是头尾两个残周可能各自只有一两天。规则越宽松，边界情形越多，这是设计上的老规律。

53 周年份的分布并不均匀。格里高利历每 400 年一个完整循环，一个循环里共 20871 周，其中 53 周的年份有 71 个，占比不到两成。相邻两个 53 周年份之间隔 5 年、6 年或者 7 年，三种间隔不规则地交替出现，靠感觉推下一个一定会错。页面上的常识卡直接算给你，不用记。

为什么日期运算要先换成整数。严肃的日期计算从不直接对「年月日」做加减，而是先换成一个连续的天序号（编程里常用「距 1970 年 1 月 1 日的天数」），加减完再换回来。年月日不是均匀的进位系统：月有 28 到 31 天四种长度，年有两种长度，规则还随世纪年变化。更要紧的是别拿两个时间戳相减再除以一天的毫秒数——实行夏令时的地区，切换那一天只有 23 小时或者有 25 小时，除下来就会差出一整天，而周数正好是「差几天再除以七」的产物，一天的误差足以让整周跳号。本页的每一个周次都建立在整数天序号上，从根上避开了这个坑。

周编号是工业界的隐形基础设施。制造业的排产计划、零售的周报、物流的发运批次、软件的迭代节奏，大量场景是以周而不是以月为单位推进的——因为月的长度不等，而周的长度恒等于七天，做同比环比时天然对齐。也正因为它这么常用，口径不一致造成的损失才格外具体：两份都标着「第 32 周」的报表，如果一份按 ISO、一份按周日开头，对的可能根本不是同一段日子。在跨部门、跨公司传数据时，把口径写进表头，比事后对账省事得多。

年份和周次要一起记。ISO 8601 规定的书写法是把年和周捆在一起写，比如第 32 周写成「XXXX-W32」，具体某一天再加一位表示星期几（周一是 1、周日是 7）。这个格式的好处是排序即时间序、长度固定、没有歧义。如果你的系统里有按周归档的需求，直接采用这个写法，年末那几天的归属问题会自动消失——因为归属年已经写在字符串里了。

这一页对自己不知道的事情保持诚实。周数是能算准的东西，所以这一页不查表、不联网、不缓存任何一年的结果，全部当场推算，也就不存在「数据过期」。但有两件事它确实不知道：一是你要的到底是哪种口径，所以三种都摆出来让你选，而不是替你决定；二是你学校或公司的第 1 周从哪天开始，所以自定义起点交给你填，起点没填就明说算不了，而不是随便给一个数字。工具类页面真正的可靠性，不在于功能多，而在于它把「我不知道」说清楚。