嘿，这个问题其实是.NET中AddMonths方法的典型行为导致的——它会尽量保留原日期的“日”部分，但如果目标月份没有对应的日期，就会自动落到该月的最后一天。咱们来拆解问题并给出不用临时调整的解决方案：

问题根源 #

5月29日运行代码时：

1. DateTimeOffset.Now.AddMonths(-3)会返回2月28日（非闰年情况下，2月没有29日，所以自动回滚到当月最后一天）
2. 2月28日调用AddMonths(3)得到5月28日，这时候和5月29日比较，5月28日 >= 5月29日不成立，断言失败。

无需临时调整的解决方案 #

方案1：调整核心判断逻辑（推荐） #

你的测试目标是验证“商品是否在近3个月内购买”，正确的逻辑应该是直接判断购买日期是否晚于等于3个月前的日期，而不是通过反向加3个月来验证。修改代码如下：

// 计算当前时间往前推3个月的日期
var threeMonthsAgo = DateTimeOffset.Now.AddMonths(-3);
// 模拟需要验证的购买日期（这里用3个月前的日期做测试）
var purchaseDate = threeMonthsAgo;
// 核心断言：购买日期 >= 3个月前的日期 → 属于近3个月内
Assert.True(purchaseDate >= threeMonthsAgo);

这种方式完全规避了AddMonths的日期回滚问题，逻辑更直接，也符合业务需求的本质。

方案2：使用DateOnly类型（.NET 6+） #

如果你的项目基于.NET 6或更高版本，可以用DateOnly类型专门处理日期逻辑，它的行为更贴合日常日期认知，同时也能避免时间部分的干扰：

var today = DateOnly.FromDateTime(DateTimeOffset.Now.Date);
var threeMonthsAgo = today.AddMonths(-3);
var purchaseDate = threeMonthsAgo;
// 调整断言逻辑为：购买日期 >= 3个月前的日期
Assert.True(purchaseDate >= threeMonthsAgo);

同样，这种方式也绕开了反向加3个月的坑，让测试逻辑更稳定。

为什么原逻辑会出问题？ #

原代码试图用purchaseDate.AddMonths(3) >= 现在来反向推导“购买日期在近3个月内”，但AddMonths的日期回滚行为会在特定日期（比如大月份的最后几天）导致计算偏差。直接比较购买日期和3个月前的日期，才是更可靠的方式。

内容的提问来源于stack exchange，提问作者DylanB