Celery Beat执行Django ORM查询为空但手动运行管理命令正常

核心原因 #

1. 时区配置不匹配（最高概率） #

这是该类问题最常见的诱因，主要有两类场景：

• Celery Worker进程的系统时区和手动执行命令的Shell环境时区不一致，代码中直接使用jdatetime.datetime.now()获取的是进程所在环境的本地时间，导致计算出的min_date、max_date范围和实际数据的时间字段不匹配。
• Celery自身的时区配置和Django项目时区配置不一致，如果Django开启了USE_TZ = True，ORM存储的时间字段为UTC时区，而手动计算的时间为Asia/Tehran时区，未做正确转换就传入查询条件，也会导致匹配不到结果。

2. 数据库连接配置不一致 #

Celery Worker启动时加载的环境变量和手动执行命令的环境变量不同，导致Worker连接的是测试库、空库而非业务数据库，自然查询不到对应数据。

3. 代码加载不一致 #

Celery Worker启动后未随代码更新重启，加载的是旧版本的模型、配置代码，和手动执行命令时的最新代码逻辑不一致，也会导致查询结果异常。

排查步骤 #

1. 先在任务handle方法中添加日志，打印min_date、max_date的值，以及Payment.objects.all().values('date')[:10]的结果，对比时间范围是否和数据的date字段匹配。
2. 在任务中打印当前数据库连接的配置信息（settings.DATABASES['default']的NAME、HOST、USER字段），和手动执行命令时的配置做对比，确认连接的是同一个数据库。
3. 重启Celery Worker进程，验证问题是否消失，排除旧代码缓存问题。

修复建议 #

1. 统一时间计算逻辑，优先使用Django自带的时区工具，避免依赖进程本地时区：

from django.utils import timezone
# 自动遵循Django settings中配置的TIME_ZONE和USE_TZ规则
min_date = timezone.now() - timezone.timedelta(hours=7)
max_date = timezone.now() + timezone.timedelta(hours=7)

2. 在celery.py中添加Celery时区配置，和Django项目时区保持一致：

app.conf.enable_utc = False
app.conf.timezone = "Asia/Tehran"

3. 启动Celery Worker前确保加载了和Django运行环境完全一致的环境变量，避免数据库连接错配。

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