Docker-Django环境下Gunicorn正常但manage.py调用旧settings.py异常

核心原因：旧的Python字节码文件（.pyc）残留 #

你的Docker构建流程中，执行collectstatic时用的是旧的settings.build.py（配置了本地MySQL），这会触发Python编译该文件生成对应的.pyc字节码文件。之后你替换了正确的settings.py，但没删除旧的.pyc文件和__pycache__目录。当开发环境运行manage.py runserver时，Python会优先加载已存在的.pyc文件，而非新的settings.py，导致读取到旧的本地MySQL配置。

为什么Gunicorn生产环境正常？ #

Gunicorn的加载逻辑和manage.py有差异：

• 你的wsgi.py中显式设置了DJANGO_SETTINGS_MODULE，加载WSGI应用时会强制重新解析settings.py，不会依赖缓存的.pyc；
• Gunicorn的工作进程启动方式会触发Python重新加载模块，跳过旧的字节码缓存。

验证方法 #

进入Django容器，执行以下命令检查是否存在旧的字节码文件：

# 查看是否有__pycache__目录或settings.pyc文件
ls -la /data/web/mysite/django_mysite/ | grep -E "__pycache__|settings.pyc"

如果存在这些文件，对比修改时间或反编译（如用uncompyle6工具）就能确认它是基于旧配置生成的。

解决方案 #

修改你的Dockerfile，在替换settings.py的同时删除旧的字节码缓存：

RUN python /data/web/mysite/manage.py collectstatic --no-input \
    && rm django_mysite/settings.py \
    && mv django_mysite/settings.tmp.py django_mysite/settings.py \
    # 添加这两行清理旧字节码
    && rm -rf django_mysite/__pycache__ \
    && rm -f django_mysite/settings.pyc

额外优化建议 #

• 调整构建顺序：把collectstatic步骤放在替换正确settings.py之后执行，从根源避免生成旧配置的字节码；
• 显式指定settings：在开发环境的Docker Compose命令中强制指定settings模块，确保加载正确文件：

  /usr/bin/python manage.py runserver 0.0.0.0:8000 --settings=django_mysite.settings
  

• 全局清理缓存：在Dockerfile中添加清理所有__pycache__目录的步骤，避免其他模块出现类似缓存问题。

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