C#日期筛选逻辑在开发与生产环境运行表现不一致问题

核心原因分类 #

• 时区/区域文化配置差异
  这是最高发的原因：IIS 服务器的系统时区、应用程序池默认区域文化和你的开发机不一致。代码中DateTime.Date的计算逻辑依赖运行环境的时区设置，如果生产服务器时区和开发机不同，计算得到的minExpDate、maxExpDate范围和你预期的完全不一致，自然查询不到匹配数据。
  另外如果aDetail.ExpiryDate的DateTime.Kind是Unspecified，ORM 生成 SQL 时会根据当前服务器的时区自动转换时间值，也会导致查询参数和开发环境不一致。
• 权限过滤问题
  你代码中使用的GenService.GetAll<T>如果内置了全局查询过滤器（比如软删除过滤、租户权限过滤、行级权限过滤），IIS 应用程序池运行身份对应的权限、租户ID和开发环境调试时的身份不一致，会导致符合条件的数据被过滤器隐藏，返回空集合后FirstOrDefault就得到Null。
  如果权限不足，部分ORM或者封装的服务会吞掉权限异常直接返回空集合，而不是抛出报错，也会导致这个现象。
• 参数值差异
  生产环境请求传入的fromWarehouseId、aDetail.ProductId、aDetail.ExpiryDate参数值和你开发环境测试的参数值不一致，比如前端传参时受区域文化影响数字、日期格式解析错误，导致查询条件根本没有匹配的数据。
• 事务隔离级别问题
  如果生产环境对应数据刚好处于未提交的事务中，且你的数据库连接默认使用读已提交及更高的隔离级别，查询时会读取不到未提交的数据，返回Null。

快速排查方法 #

在生产环境的代码中添加日志，打印minExpDate、maxExpDate、fromWarehouseId、aDetail.ProductId四个参数的具体值，同时打印ORM生成的原生SQL语句，把SQL和参数放到SQL Server中直接执行，即可快速定位是参数错误还是权限过滤问题。 #

修复建议 #

• 明确指定DateTime的Kind属性，或者直接使用DateTimeOffset类型存储和计算时间，避免时区差异导致的计算错误
• 固定应用程序的区域文化配置，在Program.cs或者Web.config中指定默认时区和文化，不依赖服务器系统配置
• 完善服务层的异常捕获逻辑，不要吞权限、SQL执行相关的异常，方便问题排查

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