Django 在 DEBUG=False 时默认不提供静态文件服务，/static/ 下所有资源（包括 admin/css/base.css）会 404，这是设计行为而非配置错误；必须通过 collectstatic 收集文件并由 Nginx/Apache 等 Web 服务器直接提供静态资源。
因为 Django 在 DEBUG=False 时完全不处理静态文件请求，所有 /static/ 路径的 CSS、JS 都会 404 —— 这不是配置错，是设计如此。
为什么 DEBUG=False 后 /static/admin/css/base.css 404
Django 的 django.contrib.staticfiles 模块只在 DEBUG=True 时启用开发服务器的静态文件服务。一旦设为 False，Django 就彻底放弃响应任何 STATIC_URL 下的请求，包括 admin 自带的 CSS。
- 这不是路径写错了，也不是
STATICFILES_DIRS没配对 —— 即使全配对，DEBUG=False下照样 404 - admin 的 CSS 实际来自
django/contrib/admin/static/，它属于 INSTALLED_APPS 中的“应用级静态资源”，开发时靠staticfiles自动聚合，生产时必须显式收集 - 浏览器控制台看到的 404 是正常的，说明 Django 已按预期“不管”这个请求了，该由 Web 服务器（Nginx/Apache/IIS）接管
python manage.py collectstatic 必须运行且路径要对
这个命令不是可选项，是生产部署的强制步骤：它把所有来源（STATICFILES_DIRS、各 app 的 static/、第三方包如 django.contrib.admin）的静态文件，统一复制到 STATIC_ROOT 指向的目录。
-
STATIC_ROOT必须是绝对路径，且 Web 服务器能直接读取（例如/var/www/myproject/staticfiles/） - 运行前确认
STATIC_ROOT目录存在且有写权限；运行后检查该目录下是否真有admin/css/子目录和对应文件 - 如果
STATIC_ROOT和 Nginx 的alias或 Apache 的Alias不一致，404 仍会发生 —— 它们必须指向同一物理位置 - 不要漏掉
--noinput参数（避免交互式确认），尤其在 CI/CD 环境中：python manage.py collectstatic --noinput
Nginx/Apache/IIS 必须显式暴露 STATIC_ROOT
Django 此时只是个纯 API 后端，静态文件服务完全交给 Web 服务器。你不能依赖 urls.py 里的 static.serve —— 它在 DEBUG=False 下被忽略，且性能极差，禁止用于生产。
立即学习“前端免费学习笔记（深入）”；
- Nginx 示例（注意
location /static/和alias末尾斜杠）：location /static/ {<br> alias /var/www/myproject/staticfiles/;<br>} - Apache 示例：
Alias /static /var/www/myproject/staticfiles<br><Directory "/var/www/myproject/staticfiles"><br> Require all granted<br></Directory>
- IIS：必须创建虚拟目录，路径精确匹配
STATIC_URL（如/static/），物理路径指向STATIC_ROOT，并启用“读取”权限
容易被忽略的硬性条件
即使上面全做对，以下任一条件不满足，CSS 依然加载失败：
-
STATIC_URL值（如'/static/'）必须与 Web 服务器配置中的 URL 前缀完全一致（含开头结尾斜杠） - 模板里引用 CSS 时，必须用
{% static 'admin/css/base.css' %}或硬编码/static/admin/css/base.css—— 不能写成./css/base.css或css/base.css - collectstatic 后，
STATIC_ROOT目录下的文件权限需允许 Web 服务器进程（如www-data）读取；常见坑是 root 执行 collectstatic，导致 nginx 无权读 - 如果用了 CDN 或反向代理，确保其缓存规则没拦截
/static/路径，或缓存了旧版 CSS 文件
