Когда я развертываю версию, я добавлю номер в строку запроса с файлом JavaScript и CSS, например, следующим образом:
'app/source/scripts/project.js?burst=32472938'
Я использую приведенное выше, чтобы разбить кеш в браузере.
Но в Firefox я получаю последний script, который я изменил. Но в Chrome я не получаю последнюю версию script, которую я модифицировал. Вместо этого я получаю старый.
Но в консоли разработчика я вижу номер пакета, который был изменен последним.
Согласно документации Google, лучший способ сделать недействительным и перезагрузить файл - добавить номер версии в имя файла, а не как параметр запроса: 'app/source/scripts/project.32472938.js'
Вот ссылка на документацию:
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#invalidating_and_updating_cached_responses
Другой способ - использовать ETag (токен проверки):
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#validating_cached_responses_with_etags
Вот как вы бы установили ETag с Nginx:
http://nginx.org/en/docs/http/ngx_http_core_module.html#etag
И наконец, учебник по кешированию браузеров с Nginx и ETag:
https://www.digitalocean.com/community/tutorials/how-to-implement-browser-caching-with-nginx-s-header-module-on-centos-7#step-2-%14-checking-the-default-behavior
Я не уверен, что это все еще применяется в наши дни, но в прошлом были случаи, когда прокси-серверы могли вызывать игнорирование значения строки запроса для целей кэширования. Там была статья от 2008 года, в которой обсуждалась идея о том, что значения строки запроса не были идеальными для нарушения кэширования, и что лучше пересмотреть имя самого файла - поэтому, ссылаясь на project_32472938.js вместо использования строки запроса,
(Я также видел в некоторых случаях некоторые необычные случаи, когда некоторые клиенты не видели эти обновления, но это казалось непоследовательным - не привязанным к Chrome, обязательно, но скорее привязанным к конкретной установке Chrome на определенном компьютере. Я бы рекомендовал проверить сайт на другом компьютере, чтобы узнать, повторяется ли там проблема, поскольку вы, по крайней мере, можете сузить его, будь то вообще Chrome или ваша конкретная установка Chrome, которая имеет проблемы.)
Все, что сказал, прошло довольно долгое время с 2008 года, и это может быть неприменимо в наши дни. Однако, если это по-прежнему является проблемой - и вы не можете найти решение основной проблемы - она по крайней мере предлагает метод, чтобы обойти его.
Я не думаю, что Chrome действительно вызывает проблему, потому что это нарушит почти все веб-приложения (например: https://www.google.com/search ? q = игла)
Возможно, ваше развертывание было немного задержано, например.
Или у вас есть CDN, как Azure между вашим веб-сервером и вашим браузером.
При стандартных настройках Azure CDN игнорирует строку запроса для кеша кэширования.
попробуйте те метатеги:
<meta http-equiv="cache-control" content="max-age=0" />
<meta http-equiv="cache-control" content="no-cache" />
<meta http-equiv="expires" content="0" />
<meta http-equiv="expires" content="Tue, 01 Jan 1980 1:00:00 GMT" />
<meta http-equiv="pragma" content="no-cache" />
Я не уверен, но для try...
google crome всегда игнорирует его.
вам нужно добавить "? random.number" или "? date.code" к каждой ссылке каждый раз, когда на вашем веб-сайте будет указан URL-адрес. например, если "myhomepage.html? 272772" хранится в кеше, то, создав новое случайное число, например "myhomepage.html? 2474789", google chrome будет вынужден искать новую копию.