浏览器是否缓存内联 Javascript，如果是，如何强制重新加载？
我们最近迁移到 jQuery 1.6，并遇到了 attr() 与 prop() 向后兼容问题。在部署更改后的最初几个小时内，一切都很好，然后就开始对人们造成影响。我们很快发现了问题并更新了有问题的 JS，这是内联的。
不，我们面临的情况是有些人仍然遇到问题。到目前为止，在每种情况下，我都可以通过告诉用户加载有问题的页面然后在浏览器中手动刷新它来让用户重新启动并运行。所以某些东西仍然必须缓存在某个地方。
但基本上只有两个潜在的罪魁祸首：首先，jQuery 库本身，但它是在查询字符串中加载版本号的，所以我认为浏览器会在缓存中刷新它。其次，内联javascript。这是否有可能被缓存在浏览器中？
我们正在使用 APC，apc.stat=1，因此它应该检测到 PHP 文件已更改。为了安全起见，我无论如何都破坏了操作码缓存。
总而言之，我有两个问题：
- 加载 jQuery 时，某些浏览器是否会忽略查询字符串？
- 某些浏览器是否会缓存旧版本的内联 JavaScript？
任何其他想法也非常受欢迎。
更新：在使用 Firebug 检查是否有任何意外缓存的过程中，我发现了旧的 jQuery 库会加载的情况。这并不能解释为什么我们在部署网站后和更新内联代码之前遇到麻烦，但如果它解决了问题，我会接受它。
We recently moved to jQuery 1.6 and ran into the attr() versus prop() back-compat issue. During the first few hours after the change was deployed everything was fine, then it started breaking for people. We identified the problem pretty quickly and updated the offending JS, which was inline.
No we have a situation where some folks are still having issues. In every case thus far, I could get the user up and running again by telling them to load the page in question then manually refresh it in the browser. So something must still be cached somewhere.
But there are basically only two potential culprits: First, the jQuery library itself, but this is loaded with the version number in the query string so I think browsers will be refreshing it in their cache. Second, the inline javascript. Is it possible that this is being cached in the browser?
We are using APC, apc.stat=1 so it should be detecting that the PHP files have changed. Just to be on the safe side I nuked the opcode cache anyway.
To summarize, I have two questions:
- Could some browsers be ignoring the query string when jQuery is loaded?
- Could some browsers be caching an older version of the inline javascript?
Any other ideas very welcome too.
UPDATE: In the course of checking that there wasn't any unexpected caching going on using Firebug, I discovered a case where the old jQuery library would load. That doesn't explain why we had trouble after deploying the site and before we updated the inline code, but if it solves the problem I'll take it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你的两个问题的答案是否定的。 除非整个页面也被缓存。
如果是这种情况，您可以尝试随页面一起发送一些标头，告诉浏览器不要缓存它。
The answer to both your questions is no. Unless the whole page is being cached as well.
If that's the case you could try sending some headers along with your page that tell browsers not to cache it.
我想说你的问题的答案是 1) 否和 2) 是。
jQuery 版本是不同的 URL，因此不存在缓存问题，除非您以某种方式直接编辑 jQuery 文件而不更改版本字符串。
浏览器页面（包括内联 JavaScript）将根据页面设置和浏览器设置（这就是浏览器的作用）进行缓存。内联 javascript 不会单独缓存，但如果网页被缓存，那么内联 javascript 也会随之缓存。您为网页设置了哪种允许的缓存（在元标记中或通过 http 标头）？
关于网页缓存控制的主题有很多值得阅读的内容此处和此处 如果需要。
当您想要推出可与浏览器中的缓存文件正常配合的升级时，规划/设计升级策略非常重要。这样做错误可能会导致您的用户要么停留在旧内容/代码上，直到缓存过期，要么更糟糕的结果是旧/新内容/代码混合在一起不起作用。
最安全的做法是在有新内容时更改源 URL。那么旧的缓存页面获取新内容的可能性为零，因此您可以避免混合的可能性。例如，在 Smugmug 照片共享网站上，每当任何网站所有者将图像更新为图像的新版本时，图像 URL 中的版本号都会更改。然后，当显示该图像的源页面从 Web 服务器提供时，它包含新的图像 URL，因此，无论旧版本的图像是否在浏览器缓存中，新版本的图像都会显示给 Web 服务器。用户。
显然，更改所有页面（尤其是顶级页面）的 URL 并不总是可行，因此这些页面通常必须设置较短的缓存设置，这样浏览器就不会长时间缓存它们，并且会定期提取新内容。
I'd say the answers to your questions are 1) No and 2) Yes.
jQuery versions are different URLs so there's no caching problems there unless you somehow edit a jQuery file directly without changing the version string.
Browser pages (including inline javascript) will get cached according to both the page settings and the browser settings (that's what browsers do). The inline javascript isn't cached separately, but if the web page is cached, then the inline javascript is cached with it. What kind of permissible caching have you set for your web pages (either in meta tags or via http headers)?
Lots to read on the subject of web page cache control here and here if needed.
It is very important to plan/design an upgrade strategy when you want to roll out upgrades that works properly with cached files in the browser. Doing this wrong can result in your user either staying on old content/code until caches expire or even worse ending with a mix of old/new content/code that doesn't work.
The safest thing to do is to change source URLs when you have new content. Then there is zero possibility that an old cached page will ever get the new content so you avoid the mixing possibility. For example, on the Smugmug photo sharing web site, whenever any site owner updates an image to a new version of the image, a version number in the image URL is changed. Then, when the source page that shows that image is served from the web server, it includes the new image URL so, no matter whether the old version of the image is in the browser cache or not, the new version image is shown to the user.
It is obviously not always practical to change the URL of all pages (especially top level pages) so those pages often have to be set with short cache settings so the browsers won't cache them for long and they will regularly pull fresh content.