Статические Файлы CSS Не Обновляются После Успешного Развертывания
У меня возникла проблема с моим приложением Django, развернутым на Railway, из-за которой изменения CSS не отражаются на реальном сайте даже после успешного развертывания и очистки кэша браузера.
Настройка проекта:
Фреймворк: Django
Статические файлы, обслуживающие: Белый шум (whitenoise.middleware.Настроены WhiteNoiseMiddleware и whitenoise.storage.CompressedManifestStaticFilesStorage)
Структура репозитория: Стандартный макет Django с manage.py, Procfile, requirements.txt в корне. settings.py/wsgi.py находятся в comparaplan/компараплане/. Статические исходные файлы предназначены для хранения в comparaplan/статическом/.
Настройка корневого каталога железной дороги: / (Корень хранилища)
Процесс развертывания и что работает:
Сборка завершена успешно.
Для команды предварительного развертывания задано значение: python manage.py migrate &&python manage.py collectstatic --noinput --clear
В журналах развертывания четко указано, что migrate и collectstatic успешно выполняются на этапе предварительного развертывания. collectstatic сообщает о копировании файлов (например, статических файлов XXX, скопированных в "/app/staticfiles").
Для команды запуска задано значение: gunicorn comparable.comparaplan.wsgi --bind 0.0.0.0:$PORT --log-file - (или оно правильно определено в Procfile, а поле команды запуска пусто).
В журналах выполнения показано, что Gunicorn успешно запускается и прослушивает правильный порт.
Приложение загружается без ошибок 5xx.
Проблема:
Несмотря на вышесказанное, изменения CSS, внесенные в файлы (специально протестированные с помощью comparaplan/static/styles/global.css), не видны на развернутом сайте.
Предпринятые шаги по устранению неполадок:
Подтвержденные изменения CSS были зафиксированы и перенесены в правильную ветку (главную) перед развертыванием.
Проверенный collectstatic успешно запускается в журналах предварительного развертывания (в том числе с использованием флага --clear).
Подтверждено settings.py:
ОТЛАДКА = Ложь
STATIC_URL = 'статический/'
STATIC_ROOT = БАЗОВЫЙ каталог / 'статические файлы'
STATICFILES_DIR = [ BASE_DIR / 'статический' ] (где BASE_DIR указывает на каталог comparaplan, содержащий manage.py)
STATICFILES_STORAGE = 'белый шум.хранилище.Сжатый манифест staticfilesstorage'
белый шум.промежуточное программное обеспечение.Присутствует белый шум-промежуточное программное обеспечение.
Несколько раз очищал кэш браузера (простая очистка, жесткое обновление Ctrl+Shift+R, окно инкогнито).
Использовал инструменты разработчика браузера (вкладка "Сеть", флажок "Отключить кэширование") для проверки ответа на файл CSS (например, global.[hash].css). Содержимое, отображаемое на вкладке "Ответ", представляет собой старую версию CSS, а не недавно внесенные изменения.
Запрос:
Не могли бы вы, пожалуйста, помочь разобраться, почему обновленные статические файлы, в частности comparaplan/static/styles/global.css, не обслуживаются, несмотря на то, что collectstatic, казалось, корректно запускался на этапе предварительного развертывания? Похоже, что White noise может обслуживать файлы из более старого каталога staticfiles, или процесс collectstatic неправильно обновляет файлы, несмотря на логи, указывающие на успешное выполнение.
Пожалуйста, дайте мне знать, если вам понадобится дополнительная информация или доступ к журналам.
Спасибо за вашу помощь!
Django ищет статические файлы в рабочей среде с помощью конфигурации веб-сервера, такой как nginx. Используйте конфигурацию Nginx, чтобы указать путь к IP-адресу вашего проекта, на котором запущен проект, он будет обслуживать статические файлы вместе с css через Nginx.
✅ Предполагаемая причина Вы используете:
STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'
Эта система хранения генерирует хэшированные имена файлов (например, global.abc123.css), а White noise обрабатывает их. Однако ваш HTML-код или шаблоны могут по-прежнему ссылаться на старый хэш, поэтому, даже если новый файл сгенерирован и собран, ваше приложение продолжает указывать на устаревший файл.