EF Core日期时间查询需用DateTimeOffset替代DateTime以保留时区、注意毫秒精度对齐、避免.Date导致索引失效，推荐范围查询替代.Date比较。
EF Core 处理日期时间查询，核心在于类型选择、精度对齐、时区意识和数据库函数利用。用错 DateTime 类型或忽略毫秒/时区，轻则查不到数据，重则跨时区显示错乱。下面说几个最常踩坑又最实用的点。
用 DateTimeOffset 替代 DateTime 存储带时区的时间
DateTime 的 Kind 属性（Utc/Local/Unspecified）只在内存中有效，一存进数据库就丢失。不同服务器本地时间写入后，数据就不可追溯。
- 实体中直接定义为
public DateTimeOffset CreatedAt { get; set; } - EF Core 会映射到 SQL Server 的
datetimeoffset类型，保留 +08:00 这类偏移信息 - 查询时可统一转成用户所在时区：比如用
TimeZoneInfo.ConvertTimeFromUtc(order.CreatedAt.UtcDateTime, userZone)
查询时注意毫秒精度对齐
数据库字段如果没存毫秒（如 SQL Server 的 datetime 类型精度是 3.33ms），而你传入带毫秒的 new DateTime(2025,12,15,10,0,0,999)，可能查不到记录。
- 查前先确认字段实际精度：SQL Server 的
datetime2(3)存毫秒，datetime不存 - 如果字段无毫秒，构造参数时用
new DateTime(2025,12,15,10,0,0)或调用.AddTicks(-DateTime.Now.Ticks % 10000)截掉毫秒 - 更稳妥的做法：用
DbFunctions.TruncateTime()或数据库原生函数做日期部分比对
按“某天”查数据，别用 .Date 比较
p.CreatedAt.Date == targetDate.Date 看似直观，但 EF Core 会把它翻译成数据库的 CONVERT(date, [CreatedAt]) = '2025-12-15'，可能无法走索引，尤其在大数据量时明显变慢。
- 推荐写法：用范围查询
p.CreatedAt >= startOfDay && p.CreatedAt - startOfDay = new DateTime(2025,12,15)，nextDay = startOfDay.AddDays(1)
- 这样能命中
CreatedAt字段上的索引，性能稳定
需要数据库当前时间，别用 DateTime.Now
客户端时间 ≠ 数据库时间，尤其跨服务器或有 NTP 偏差时。业务逻辑依赖“服务端此刻”必须查数据库。
- EF Core 没有
SqlQuery，但可用Database.ExecuteSqlRaw或FromSqlRaw配合标量查询 - SQL Server：
_context.Database.SqlQueryRaw($"SELECT GETDATE()").First() - MySQL：
_context.Database.SqlQueryRaw("SELECT NOW()").First() - 也可封装成扩展方法，统一获取服务端时间戳
基本上就这些。不复杂，但容易忽略精度、时区和索引友好性这三个关键点。
