Django 3.2升级至4.2后部署环境Admin静态文件加载失败排查

1. 验证Docker容器内静态文件的权限与路径 #

• 进入Docker容器执行 ls -l /usr/share/nginx/html/static/admin/css/，确认dark_theme.css的所有者、权限是否允许Nginx进程读取（Linux环境下Nginx通常用www-data用户，文件需至少具备r权限）。
• 核对浏览器请求的路径与容器内实际路径是否完全匹配：比如浏览器请求/static/admin/css/dark_theme.css，容器内对应路径应为/usr/share/nginx/html/static/admin/css/dark_theme.css，注意Linux环境大小写敏感。

2. 检查Nginx配置的细节问题 #

• 确认alias路径末尾的斜杠是否存在：当前配置alias /usr/share/nginx/html/static/;是正确的，若缺失末尾斜杠会导致路径拼接错误。修改后执行nginx -s reload重启Nginx。
• 查看Nginx错误日志（通常路径为/var/log/nginx/error.log），搜索dark_theme.css相关条目，日志会显示Nginx实际查找的文件路径，直接定位问题根源。

3. 确认CI/CD流程中collectstatic的执行环境 #

• 检查CI流程执行collectstatic时，是否使用了Django 4.2版本及对应依赖。若CI环境仍保留Django 3.2的依赖，collectstatic不会生成4.2新增的dark_theme.css文件。
• 确保CI执行collectstatic时添加--noinput参数以非交互式完成，避免流程中断导致文件未完全生成，完整命令为：python manage.py collectstatic --clear --noinput。

4. 检查Django静态文件的版本化与缓存配置 #

• 若之前配置过静态文件版本化（如ManifestStaticFilesStorage），清理CI环境中旧的静态文件哈希缓存，避免新文件URL被旧缓存覆盖。
• 在浏览器开发者工具中查看dark_theme.css的完整请求URL，确认是否带有旧哈希后缀，若存在可在URL后追加?v=4.2临时强制绕过缓存测试。

5. 验证Django Admin静态文件的收集完整性 #

• 本地执行collectstatic后，对比本地STATIC_ROOT下admin/css/目录与容器内对应目录的文件列表，确认dark_theme.css的大小、修改时间完全一致，排除文件复制过程中损坏或丢失的可能。

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