DEBUG=False时Django信号失效，缓存未清除问题求助

1. AppConfig未被正确加载（最常见原因） #

Django仅在INSTALLED_APPS中指定完整的AppConfig类路径时，才会执行ready()方法。如果你的配置里写的是'apps.hub'而非'apps.hub.apps.HubConfig'，ready()方法不会触发，信号自然无法注册。

解决方法：
修改settings.py中的INSTALLED_APPS配置：

INSTALLED_APPS = [
    # ... 其他应用
    'apps.hub.apps.HubConfig',  # 替换原有的'apps.hub'
]

2. 生产服务器多进程/懒加载机制导致信号失效 #

生产环境的WSGI/ASGI服务器（如uWSGI、Gunicorn）通常启用多进程模式或懒加载，可能导致ready()方法未在所有进程中执行，或模块重复加载引发信号注册异常。

解决方法：

• 针对uWSGI：添加lazy-apps = true配置，确保每个worker进程都会正确加载AppConfig并执行ready()。
• 或者在ready()方法中添加防重复执行的判断：

from django.apps import AppConfig

class HubConfig(AppConfig):
    default_auto_field = 'django.db.models.BigAutoField'
    name = 'apps.hub'
    _signals_loaded = False

    def ready(self):
        if not self._signals_loaded:
            from . import signals
            self._signals_loaded = True

3. 生产环境缓存配置异常（信号触发但缓存操作无效） #

有时信号实际已触发，但生产环境的缓存后端（如Redis、Memcached）配置错误，导致cache.delete("markers_frontend")未真正清除缓存，看起来像是信号失效。

排查与解决：

• 在生产环境Django shell中测试缓存读写：执行cache.set("test_key", "test_val")和cache.get("test_key")，确认缓存后端正常工作。
• 检查settings.py中的CACHES配置，确保生产环境与开发环境的键名规则一致（比如是否存在前缀差异）。

4. 信号注册方式的潜在问题 #

使用@receiver装饰器依赖模块导入时自动注册，若AppConfig加载顺序异常或存在冲突的信号注册，可能导致信号绑定失败。

替代方案：
放弃@receiver装饰器，在ready()方法中显式注册信号：

from django.apps import AppConfig
from django.db.models.signals import post_delete, post_save

from apps.hub.models import Marker
from apps.hub.signals import clear_cache_delete_handler, clear_cache_save_handler

class HubConfig(AppConfig):
    default_auto_field = 'django.db.models.BigAutoField'
    name = 'apps.hub'

    def ready(self):
        post_delete.connect(clear_cache_delete_handler, sender=Marker, dispatch_uid="marker_deleted")
        post_save.connect(clear_cache_save_handler, sender=Marker, dispatch_uid="marker_updated")

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