django-compressor/libsass生成的压缩CSS首次启动服务不返回，重启后正常

问题原因 #

这个问题是Django开发服务器（runserver）的静态文件处理逻辑与django-compressor的缓存机制冲突导致的，具体逻辑如下：

• 当DEBUG=False且未加--insecure参数时，Django默认不会直接扫描STATIC_ROOT目录下的所有文件来响应静态请求，而是依赖配置的STATICFILES_FINDERS来查找文件。
• 你执行collectstatic时django-compressor虽然已经生成了压缩后的CSS文件和对应的缓存映射清单，但首次启动runserver时，compressor.finders.CompressorFinder不会主动预加载离线生成的缓存清单，首次请求压缩文件时无法正确映射路径到实际存在的文件，因此返回404。
• 重启服务后恢复正常，是因为首次运行过程中compressor已经读取到了缓存清单并完成了路径注册，第二次启动时可以直接读取已加载的缓存映射，因此能正常找到文件。
• 加--insecure参数无问题，是因为该参数会强制Django开发服务器跳过查找器校验，直接从STATIC_ROOT目录读取对应路径的文件返回，不受查找器逻辑限制。

是否需要修复后再部署 #

不需要专门修复即可部署到Heroku。这个问题仅存在于本地使用runserver启动服务的场景，Heroku生产环境不会使用runserver作为服务器，会使用Gunicorn等WSGI服务配合WhiteNoise处理静态文件：WhiteNoise会在服务启动时全量扫描STATIC_ROOT下的所有文件（包括CACHE目录下的压缩资源），直接响应静态请求，不会触发这个问题。

如果要在本地DEBUG=False环境下规避该问题，可在配置中添加COMPRESS_OFFLINE = True，开启离线压缩模式，强制compressor启动时直接读取collectstatic生成的离线缓存清单，即可解决首次启动404的问题。

内容的提问来源于stack exchange，提问作者Amos P