写在html页面的js代码加上$(document).ready会被缓存吗_如何在团队中推广一项技术 —— 解决一站式微前端的缓存问题

引言

对于一个工程师而言，不仅要有过硬的自身本领，还要有一定的技术影响力。当我们解决一个问题之后，如何在团队中顺利的推广并落地，也同样重要。接下来，想给大家分享一下，我在团队中推广一项技术解决方案的全过程。

问题的出现

年前的时候，我们团队对公司内部某平台的微前端方案进行了改造和升级。最早是通过 iframe 来完成这一方案的。

iframe 作为一个非常 “古老” 的，人人都觉得普通的技术，却一直很管用。它能有效地将另一个网页/单页面应用嵌入到当前页面中，两个页面间的 CSS 和 JavaScript 是相互隔离的——除去 iframe 父子通信部分的代码，它们之间的代码是完全不相互干扰的。iframe 便相当于是创建了一个全新的独立的宿主环境，类似于沙箱隔离，它意味着前端应用之间可以相互独立运行。

但是 iframe 不够灵活。它会使路由、历史记录和深层链接变得更加复杂，并且很难做成响应式页面。

于是，团队决定使用 Web Components 的方案来替代 iframe。

Web Components 是一套不同的技术，允许开发者创建可重用的定制元素（它们的功能封装在代码之外），并且在 web 应用中使用它们。

我们上线这一方案之后遇到一个问题：用户刷新浏览器之后没有看到系统的更新。由于我们注册子服务时，使用的是一个不带哈希 js 文件来注册的。而代理层对于这部分静态资源的缓存策略是会缓存下来的。这种死文件名的方式就使得缓存的问题重新暴露了出来，用户使用我们的系统时，需要强制刷新或者不使用缓存，才能看到系统更新的内容。

当然，也可以让接入层设置不缓存所有文件。但是这样的话每次都需要请求所有文件，十分影响性能。而且需要频繁修改Nginx的配置，会增加跨部门协作的成本。可能就将一个简单的问题复杂化了。

获得灵感

本着 “我一定不是第一个遇到这个问题的人” 的思想，一个技术问题一般会有如下的解决方案：

• 1、google 搜索
• 2、当一个伸手党
• 3、开源社区提问
• 4、探究原理，明白到底发生了什么
• 5、看源码，尝试自己解决

其实，前3个方式都是提问，只是方式不同罢了。但是如果可以问对人，那么一定是最快的方式。

而我这次可以解决这个技术难题，也源自我参加了2020年1月11日Node party线下分享。阿里的流司分享的主题，就是《⾯向B端⼯作台的微前端⽅案-ConsoleOS》。在分享结束的时候，我向他提出了我的疑问。他们的方案中是使用 manifest 来解决一个入口，多个文件的问题的。manifest.json 中，可以保存子系统多版本的所有资源文件。这样的话，只需要写死一个入口，里面的资源文件就可以加上哈希后缀，从而解决这一问题。

解决问题

第二天，我就冲到公司，对主系统和子系统进行了改造。折腾了一天之后，就完成了这个方案的第一版：使用 manifest.json 作为入口文件，加载子系统。

在推行这个方案的时候，起初是没有被采纳的。原因如下：

• 演示不够具有说服力。Demo 中只能演示上图的加载过程，并没有完整的演示缓存问题的解决。
• 跨部门协作成本较大。接入层的缓存策略一般是不缓存 index.html ，manifest.json也是会缓存的，这个方案需要接入层调整代理配置，代价较大。
• 方案不具备通用性。每一个子系统在打包的时候，命令和配置不是完全一样的。这个方案不一定适用于每个子系统。
• 风险不可控。方案中没有考虑到测试，到上线各个阶段的注意点。访问的链路增加，是否会影响性能？子系统发布之后，是否会影响到一站式，和老系统的使用？
• 没有通俗易懂的文档。

让你方案变得可靠

工程师的真正价值就是把未知变成已知的能力。但是一个想法从知道，到实际落地，还是存在一定距离的。

• 1、探究原理。在这个过程中，我做的第一件事，还是去了解这个问题发生的根本原因，了解 HTTP 缓存 的原理。

• 2、降低跨部门协作成本。在明白原理并与后端同学沟通之后，明白接入层不会缓存 index.html 这个高频更新的文件，于是就优化了链路。

• 3、让方案变得通用。接下来，就需要明确各个系统的接入层缓存配置，并且对几个典型的系统进行改造，发到测试环境。
• 4、让方案可以兼容各个阶段。上线的时候，所有系统的更新会有先有后。在打包子系统的时候，不仅会生成新系统需要的 manifest.json，还会生成老版本一站式所需要的 entry.js 文件。让整个升级变得更加平滑，不会出现系统不可用的情况。
• 5、健全的文档。梳理子系统的改造过程，将子系统改造的每个步骤写清楚，以及遇到各种情况的处理方案。

这次，方案终于通过，可以进入实际改造的环节。

积极地帮助他人

在这里，容我先放一张沙雕图..

不同的人，对于同一个方案的理解，有时候可能会有些差异。而且，其实我在整理方案的时候，并没有考虑到所有情况。

这个时候，就需要扮演好客服，以及售后的角色了。第一时间帮助同事解决出现的各种情况。

总结

跌跌撞撞一个月，在小伙伴的协助下，这个方案最终还是上线了。体验地址：Odin 。

之前有看张铁蕾老师的文章《技术攻关：从零到精通》，文中讲到如何解决一个从来没接触过的任务：

• 研究问题本身：先研究问题本身是怎么产生的
• 对专业领域的Overview：花最短的时间快速了解相关的各个概念
• Run起来，获得感性认识
• 同行交流：能够Run起一个实现，并从API层面粗略地了解一项技术之后，在这个认识的基础上，我们就差不多可以找同行交流一下了。
• 研究Spec：所谓Spec，是集中体现该项技术的设计思想的东西，是高度抽象的描述，一般也是一份完备的、系统性的描述。
• 研究和选择具体实现
• 研究相似产品的实现
• 网上浏览最佳实践
• 结合自己的系统设计方案
• 系统实现的过程

到这里，问题应该已经得到了解决。但是真正要推广开来，还需要：

• 沟通，听取他人意见。去了解当前方案需要哪些人的协助，举办评审会，收集、听取他人的建议。
• 确定影响范围，增强方案的兼容性。
• 通俗易懂，经得起反复推敲的文档。

如果可以做到这些，相信难题也可以迎刃而解了~

---

• 滴滴云采购季限时特惠，秒杀1C1G1M仅9.9元/月
• 滴滴云使者专属特惠，包年云服务器低至68元/年

滴滴云-为开发者而生​www.didiyun.com

滴滴云使者​www.didiyun.com