Django 的 collectstatic 默认不压缩文件，因其专注后端职责，静态资源压缩交由专业工具链（如 webpack、vite 或 django-compressor）处理；生产环境推荐构建时压缩+哈希命名+CDN缓存。
为什么 collectstatic 默认不压缩文件
Django 的 collectstatic 命令只是把散落在各 app 的 static 目录下的资源合并到 STATIC_ROOT，它本身不执行任何压缩逻辑——这是故意设计的：Django 专注后端职责，静态资源优化交给更专业的工具链处理。如果你发现 CSS/JS 文件体积大、加载慢，问题大概率不在 Django 配置，而在缺少构建时的压缩步骤。
用 django-compressor 在模板中实时压缩
适合开发阶段快速验证或无法接入构建流程的部署环境（如某些 PaaS）。它在模板渲染时读取原始 CSS/JS，调用外部命令（如 cssnano、terser）压缩，并缓存结果。
关键点：
- 必须在
INSTALLED_APPS中加入'compressor'，并在TEMPLATES的OPTIONS['context_processors']里加'compressor.context_processors.compressor' - 模板中不能直接写
<link rel="stylesheet">，得用{% load compress %}+{% compress css %}...{% endcompress %} - 压缩依赖外部二进制：需提前装好
node和npm install -g terser cssnano，否则运行时报CommandError: Unable to locate 'terser' - 生产环境务必设置
COMPRESS_ENABLED = True和COMPRESS_OFFLINE = True，否则每次请求都触发压缩，严重拖慢响应
用 webpack 或 vite 独立构建再交由 Django 托管
这才是现代前端的标准做法：把静态资源当成独立项目构建，生成带哈希名的压缩产物，再让 Django 的 collectstatic 拷过去。Django 只负责托管和 URL 分发，不参与构建逻辑。
立即学习“Python免费学习笔记（深入）”；
实操要点：
- 在项目根目录外新建
frontend/，用vite create初始化，配置build.outDir: '../static/dist' - 修改 Django 的
STATICFILES_DIRS，加入os.path.join(BASE_DIR, 'static', 'dist')，这样collectstatic才能发现构建产物 - 模板中用
{% static 'dist/main.[hash].js' %}不现实——哈希值是构建时生成的，Django 运行时不知道。正确方式是让构建工具输出manifest.json，再用自定义模板标签读取映射 - 避免把
node_modules放进STATICFILES_DIRS，否则collectstatic会试图拷贝整个目录，耗时且易出错
CDN 配合指纹文件失效，别只靠 Gzip
Gzip 是 HTTP 层压缩，对已压缩的 JS/CSS 效果有限；真正起效的是构建时压缩 + 文件名哈希 + CDN 缓存。如果没配 CDN，光靠 Django 开启 gzip 中间件，提升非常有限。
必须检查的三项：
-
STATICFILES_STORAGE是否设为ManifestStaticFilesStorage？它会在collectstatic时重命名文件并生成staticfiles.json，确保 HTML 引用的是带哈希的新路径 - Nginx/Apache 是否配置了
expires 1y和add_header Cache-Control "public, immutable"？没有这些，浏览器不会长期缓存 - CDN 的源站回源路径是否指向
STATIC_ROOT而非开发时的static/目录？回源错路径会导致 CDN 拉到未压缩的原始文件
构建产物的哈希值是缓存失效的唯一可靠依据，其他所有“强制刷新”“清缓存”操作都是临时补救。
