DateTime.DayOfWeek 默认值因地而异，正确做法是依据 CultureInfo.CurrentCulture.DateTimeFormat.FirstDayOfWeek 获取本周第一天，或使用 .NET 6+ 的 ISOWeek.GetFirstDayOfWeek 绕过文化依赖，避免直接用 DayOfWeek 枚举值做算术运算。
DateTime.DayOfWeek 默认值因地而异，别硬写 Monday=1
很多开发者直接用 DateTime.Today.AddDays(-1) 或 DateTime.Today.AddDays(-DateTime.Today.DayOfWeek) 算“周一”，结果在某些系统上返回周日——因为 DayOfWeek 枚举的底层值依赖当前线程的 CultureInfo，DayOfWeek.Sunday 恒为 0，但“本周第一天”未必是 Sunday。Windows 区域设置为中文时，CultureInfo.CurrentCulture.DateTimeFormat.FirstDayOfWeek 才是真实起点。
- 正确做法：先获取文化信息中的首日，再计算偏移量
- 避免用
DayOfWeek.Monday做减法，除非你明确要求 ISO 8601（周一为始）且不关心本地化 - 若业务强制要求“周一为本周第一天”，应显式指定
CultureInfo.InvariantCulture或用ISOWeek.GetYearWeekAndDay（.NET 6+）
使用 DateTime.Now 与 DateTime.Today 的区别影响精度
DateTime.Today 返回当天 00:00:00，适合纯日期逻辑；DateTime.Now 包含时分秒毫秒，若直接用于“本周第一天”计算，可能因时间截断导致跨天偏差（尤其在临界时刻如周一 00:00:00.001）。多数业务场景要的是“日期粒度”的周一，不是“带时间戳的周一凌晨”。
- 推荐统一用
DateTime.Today开始计算，避免意外携带时间部分 - 如果需保留原始时间上下文（如日志分析），先
.Date截断再算，不要对Now直接做AddDays - 注意
DateTimeKind：若涉及时区转换，DateTime.SpecifyKind或TimeZoneInfo.ConvertTime必须提前处理，否则FirstDayOfWeek可能错位
.NET 6+ 推荐用 ISOWeek.GetFirstDayOfWeek
.NET 6 引入了 ISOWeek 类型，原生支持 ISO 8601 标准（周一为每周第一天，第一周包含当年第一个周四）。它绕开了 CultureInfo 的干扰，语义更清晰，也更适合国际化系统。
var today = DateOnly.FromDateTime(DateTime.Today); var firstDay = ISOWeek.GetFirstDayOfWeek(today.Year, today.IsoWeekNumber);
- 返回的是
DateOnly，天然无时间部分，避免DateTime的精度陷阱 - 不依赖当前线程文化，行为确定，测试可预测
- 注意：年份可能跨年——例如 2024-01-01 是周一，但属于 ISO 2023 年第 52 周，
GetFirstDayOfWeek(2023, 52)才是它
常见错误：忽略跨年周、误用 DayOfWeek 数值做减法
典型错误代码：date.AddDays(-(int)date.DayOfWeek)。这假设 Sunday=0 就是本周开始，但 2024-12-31 是周二，按此算法会得到 2024-12-29（周日），而实际 ISO 第一周从 2024-12-30（周一）开始——差一天；更糟的是，2025-01-01 是周三，该算法算出 2024-12-29，但那天属于 2024 年第 52 周，不是 2025 年第 1 周。
- 永远不要把
DayOfWeek枚举值当“本周第几天”直接参与算术，它只是星期几，不定义周边界 - 跨年周是高频坑点，尤其在财务/报表系统中，必须区分“日历周”和“ISO 周”
- 如果用老版本.NET（CultureInfo.CurrentCulture.DateTimeFormat.FirstDayOfWeek 并做模运算，而不是硬编码数字
真正难的不是算出一个周一，而是让这个“周一”在所有环境、所有年份、所有文化下都指向业务认可的“本周第一天”。文化、标准、跨年、时区——漏掉任意一个，上线后都可能在某台服务器上悄悄错一天。
