已部署Django应用（Docker+gunicorn+whitenoise+Heroku）无法提供静态文件服务

你遇到的500错误和静态文件本身是否存在无关，核心问题出在两点：

1. 自定义请求日志中间件的代码逻辑缺陷：WhiteNoise返回的静态文件响应是WhiteNoiseFileResponse类型的流式响应，没有content属性，你的日志代码直接读取response.content触发了属性异常。
2. 中间件排序错误：你将自定义日志中间件放在了WhiteNoise中间件之前，所有静态文件请求的响应都会先经过你的日志中间件处理，直接触发错误。

1. 修改自定义日志中间件逻辑 #

修改/app/secure_my_spot/custom_middleware/request_logging.py中访问response.content的代码，先判断响应类型是否为流式响应：

# 原代码：print(f"Content: {response.content}")
# 替换为以下逻辑
if not getattr(response, 'streaming', False):
    print(f"Content: {response.content}")
else:
    # 流式响应（含WhiteNoise返回的静态文件）不读取content属性
    print("Content: [流式响应，跳过内容读取]")

2. 调整中间件排序 #

修改settings.py中的MIDDLEWARE配置，将自定义日志中间件移动到WhiteNoise中间件之后，避免静态文件响应提前触发日志逻辑：

MIDDLEWARE = [
    "corsheaders.middleware.CorsMiddleware",
    "django.middleware.security.SecurityMiddleware",
    "whitenoise.middleware.WhiteNoiseMiddleware",
    # 自定义日志中间件移到此处
    "secure_my_spot.custom_middleware.request_logging.RequestLogging",
    "django.contrib.sessions.middleware.SessionMiddleware",
    "django.middleware.common.CommonMiddleware",
    "django.middleware.csrf.CsrfViewMiddleware",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
    "django.contrib.messages.middleware.MessageMiddleware",
    "django.middleware.clickjacking.XFrameOptionsMiddleware",
]

可选优化（非必须） #

你在Dockerfile构建阶段和heroku_entrypoint.sh启动阶段各执行了一次collectstatic，属于冗余操作，可以删除其中任意一处的python manage.py collectstatic --noinput命令，减少部署耗时。

修改完成后重新部署到Heroku，访问管理后台路由即可正常加载样式资源。

内容的提问来源于stack exchange，提问作者Sven Gerlach