Django项目Docker化常见问题根源在于环境变量未透传、ALLOWED_HOSTS未动态配置、数据库启动时序不当；需用healthcheck+重试逻辑替代depends_on，分层构建优化pip缓存，并确保静态文件路径与Nginx映射一致。
为什么Django项目一进Docker就500或连不上数据库
根本原因通常是环境变量没透传、ALLOWED_HOSTS没动态适配、或者Django启动时数据库还没就绪。Docker容器启动是异步的，python manage.py runserver不会等postgres容器ready就直接报ConnectionRefusedError。
- 用
depends_on只控制启动顺序，不保证服务就绪——得自己加健康检查或重试逻辑 -
ALLOWED_HOSTS不能写死成['localhost']，要设为['*']（开发）或从HOSTNAME环境变量读取（生产） - 数据库连接地址别用
localhost，必须用db（对应docker-compose里service名） - DEBUG=True时，静态文件路径容易错：Docker里
STATIC_ROOT要和Nginx映射路径一致，否则404
Dockerfile里Python依赖安装为什么总缓存失效
因为requirements.txt内容变了，但Docker构建时把整个.复制进去太早，导致每次改代码都重装所有包。关键在分层——先把requirements.txt单独COPY，再RUN pip install，最后才COPY源码。
- 错误写法：
COPY . /app→RUN pip install -r requirements.txt（只要任一文件变，pip这层全失效） - 正确顺序：
COPY requirements.txt /app/→RUN pip install -r requirements.txt→COPY . /app - 用
--no-cache-dir避免pip缓存污染镜像层（尤其CI环境） - 生产镜像建议用
python:3.11-slim而非python:3.11，体积小一半，少一堆dev工具
docker-compose.yml里怎么让Django等PostgreSQL启动完再跑
靠healthcheck + restart: on-failure组合，而不是只信depends_on。PostgreSQL官方镜像自带healthcheck，但Django侧得自己加等待逻辑。
- PostgreSQL service里保留默认
healthcheck（检查5432端口+pg_isready） - Django service里删掉
depends_on的简单写法，改用depends_on: { db: { condition: service_healthy } } - 更稳的做法：在Django容器启动脚本里加
wait-for-it.sh db:5432 -- python manage.py migrate，避免migrate失败卡住 - 别在
command里直接写python manage.py runserver——它不支持热重载，用gunicorn替代
本地开发用Docker时manage.py命令怎么执行
不能直接docker exec -it myapp python manage.py migrate，因为容器里可能没装psycopg2编译依赖（比如gcc、postgresql-client），或者settings.py加载的是生产配置。
立即学习“Python免费学习笔记（深入）”；
- 开发镜像要额外装
build-essential和libpq-dev，不然psycopg2编译失败 - 用
docker-compose run --rm web python manage.py migrate（web是service名），确保走同一套环境变量和依赖 - 调试时想进shell：
docker-compose run --rm --service-ports web bash，再手动运行命令 - 注意
manage.py里os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings.development')得明确指向开发配置，别被DJANGO_SETTINGS_MODULE环境变量意外覆盖
最常被跳过的点：Docker里collectstatic生成的静态文件路径，和Nginx配置的alias必须完全一致，差一个斜杠都会404。还有就是SECRET_KEY绝不能硬编码进Dockerfile，必须走environment或secrets注入。
