static_url 应写为绝对路径 /static/，既保证浏览器正确访问，又避免子路径部署错乱；开发用此值，上线后通过 nginx 或 staticfiles_storage 切换 cdn。
STATIC_URL 写成相对路径还是绝对路径？
STATIC_URL 的作用是告诉 Django 模板里 {% static %} 标签最终生成什么前缀，它不指向本地文件系统，只用于拼接 URL。写成 /static/ 是最稳妥的选择——浏览器能直接访问，Django 也能正确解析。别写成 static/（缺开头斜杠），否则在子路径部署时会变成 /admin/static/ 这种错乱路径；也别写成 https://cdn.example.com/static/ 这种完整 URL（除非你真用 CDN 且已配好白名单），否则开发时本地静态文件就彻底失效了。
- 开发阶段建议始终用
/static/，上线后可通过 Nginx 或STATICFILES_STORAGE切换 CDN - 如果项目跑在子路径下（比如
https://example.com/myapp/），STATIC_URL仍应为/static/，而不是/myapp/static/——Django 不会自动感知子路径，得靠反向代理或前端路由配合
STATICFILES_DIRS 里放什么、不放什么？
STATICFILES_DIRS 是一个列表，告诉 Django 哪些目录里的文件要被 python manage.py collectstatic 扫描并收集。它只管「源」，不管「目标」；它的路径必须是绝对路径，且不能包含 STATIC_ROOT 目录本身（否则会循环收集）。
- 典型内容：
BASE_DIR / "static"（项目级公共静态资源）、BASE_DIR / "apps/core/static"（按 App 组织的静态文件） - 不要把
STATIC_ROOT加进去，比如BASE_DIR / "staticfiles"——collectstatic 会报错或无限递归 - 别用相对路径字符串如
"static"，Python 3.4+ 推荐用Path对象，避免os.path.join在 Windows 下出错 - 多个目录时顺序重要：前面的同名文件会覆盖后面的，适合做“主题覆盖”场景
DEBUG=False 时 collectstatic 失败但没报错？
这是最常踩的坑：DEBUG=False 后，Django 默认不再通过视图服务静态文件（django.contrib.staticfiles.views.serve 被禁用），而 collectstatic 又没运行或路径不对，结果页面里所有 {% static %} 都生成了 URL，但 Nginx/Apache 根本找不到对应文件，返回 404。浏览器开发者工具 Network 标签下能看到一堆 404，但控制台可能不报 JS 错误，容易误判为代码问题。
- 上线前必做：
python manage.py collectstatic --noinput，确认输出日志里有 “X static files copied” - 检查
STATIC_ROOT是否设为绝对路径，且 Web 服务器（如 Nginx）的 location 块是否真实指向该目录，比如alias /var/www/myproject/staticfiles/;（注意结尾斜杠） - 别依赖
runserver在DEBUG=False下“凑合跑”，它根本不会加载 staticfiles URL 路由
为什么 collectstatic 后 CSS/JS 文件还是 404？
常见原因不是配置错，而是缓存和路径映射没对上。collectstatic 默认按文件内容哈希重命名（如 main.a1b2c3d4.css），但模板里引用的仍是原始名 main.css——这依赖 ManifestStaticFilesStorage 和 {% static %} 的联动。如果没启用哈希存储，或用了自定义存储但没重写 url() 方法，就可能出现“文件存在但 URL 不匹配”。
- 确认
STATICFILES_STORAGE是django.contrib.staticfiles.storage.ManifestStaticFilesStorage（开发可不用，上线推荐） - 模板中必须用
{% load static %}+{% static "css/main.css" %}，不能硬编码/static/css/main.css - 修改静态文件后记得重新
collectstatic，否则哈希值不变，旧缓存依然生效 - 浏览器强刷（Ctrl+F5）或清空 DevTools 的 “Disable cache” 勾选，排除本地缓存干扰
