一个简单的前端项目：
“简单”的 页面和它的样式文件 a.css ，用文本编辑器写好代码，无需编译，本地预览，确认OK，丢到服务器，等待用户访问。
OK了。
然后我们访问页面，看到效果，再查看一下网络请求，200。很OK。
看看那个 a.css 文件的请求吧，如果每次用户访问页面都要加载，是不是很影响性能，很浪费宽带，我们希望变成这样：
利用 304 ，让浏览器使用本地缓存。但，这样就够了吗？不行，304 叫协商缓存，这玩意还是要和服务器通信一次，我们希望更完美，所以必须彻底消灭掉这个请求，变成这样：
强制浏览器使用本地缓存（cache-control/expires），不要和服务器通信了。好了，现在网络请求优化已经做的很好了，那问题来了：你都不让浏览器发资源请求了，这缓存如何更新呢？
很好，相信有人想到了办法：通过更新页面中引用的资源路径，让浏览器主动放弃缓存，加载新资源。就像这样：
下次上线，把链接地址改成新的版本，就更新资源了不是吗。OK，问题解决了吗？当然没有。。。
我们来看下面这种情况：
页面引用了 3 个 css ，而某次上线只改了其中的 a.css，如果所有链接都更新版本，就会导致 b.css 、c.css 的缓存也失效，那岂不是又有浪费了？！！
我们不难发现，要解决这种问题，必须让 url 的修改与文件内容关联，也就是说，只有文件内容变化，才会导致相应 url 的变更，从而实现文件级别的精确缓存控制。
什么东西与文件内容相关呢？我们会很自然的联想到利用数据摘要算法，对文件求摘要信息，摘要信息与文件内容一一对应，就有了一种可以精确到单个文件粒度的缓存控制依据了。好了，我们把 url 改成带摘要信息的：
这回再有文件修改，就只更新那个文件对应的 url 了，想到这里感觉很完美了。
但显示的情况是：现在互联网企业，为了进一步提升网站性能，会把静态资源和动态网页分集群部署，静态资源会被部署到 CDN 节点上，网页中引用的资源也会变成对应的部署路径：
好了，当我要更新静态资源的时候，同时也会更新 html 中的引用，就好像这样：
这次发布，同时改了页面结构和样式，也更新了静态资源对应的 url 地址，现在要发布代码上线。
我想要你告诉我，是先部署页面，还是先部署静态资源？？
1、先部署页面，再部署资源：在二者部署的时间间隔内，如果有用户访问页面，就会在新的页面结构中加载旧的资源，并且把这个旧版本的资源当做新版本缓存起来，其结果就是：用户访问到了一个样式错乱的页面，除非手动刷新，否则在资源缓存过期之前，页面会一直执行错误。
2、先部署资源，再部署页面：在部署时间间隔之内，有旧版本资源本地缓存的用户访问网站，由于请求的页面是旧版本的，资源引用没有改变，浏览器将直接使用本地缓存，这种情况下页面展现正常；但没有本地缓存或者缓存过期的用户访问网站，就会出现旧版本页面加载新版本资源的情况，导致页面执行错误，但当页面完成部署，这部分用户再次访问页面又会恢复正常了。
好的，上面的分析想说的是：先部署谁都不成！都会导致部署过程中发生页面错乱的问题。所以，访问量不大的项目，可以让研发同学苦逼一把，等到半夜偷偷上线，先上静态资源，再部署页面，看起来问题少一些。
这个奇葩问题，起源于资源的 覆盖式发布，用 待发布资源 覆盖 已发布资源，就有这种问题。解决它也好办，就是实现 非覆盖式发布。
如对本文有疑问， 点击进行留言回复！！
css深入剖析transform的translate和perspective
HCIE第四天总结（典型组网之一：CSS+Eth-Trunk+iStack）
了解下Apache Elasticsearch 和 Kibana
我要评论
网友评论