方案变迁

1. 链接（不集成），a标签跳转（简单，无通讯）
2. iframe（集成）（简单，通讯成本高（样式js），seo不能同时收录）
3. ajax（集成）（简单，样式js容易冲突，多请求三剑客，变慢）
4. ssi（集成）（复杂，需要服务端配合，请求少，展现快，但万一某片运行缓慢）进阶首屏ssi+剩余ajax（不适合用户需要快速交互的场景）
5. 自定义标签（客户端集成）（Shadow DOM样式隔离）
6. 统一SPA（single-spa集成）不同dom对应不同技术挂载起点即同一个html外壳（还需处理路由）
7. 同构（服务端渲染一遍，客户端根据需要或再渲染一遍）（技术要求高，但同时获得首页快速呈现和交互快速响应）

// d定义
class CheckoutBuy 
extends HTMLElement 
{
connectedCallback() {
this.innerHTML = "<style>button {}</style><button>buy now</button>";
} }
window.customElements.define("checkout-buy", CheckoutBuy); // 可以写在最后，此前checkoutbuy只是无效标签，一旦define直接替换成button
// 使用
var a = document.createElement('checkout-buy')
document.body.prepend(a)
// 效果：<checkout-buy><button>buy now</button></checkout-buy>

6. 通讯手段

1. dispatchEvent on 发布订阅
2. BroadcastChannel 发布订阅
3. CustomEvent addEventListener
4. 服务端

7. 路由

1. 将不同spa组合成一个应用（顶级，团队级两级都用 window.appHistory.listen）

9. 架构选型

1. 好问题: 是建站还是应用程序？ 极端例子: 以内容为中心的博客 vs 以功能为中心的画图导出
2. 分不清则用排除法： 如亚马逊，排除除了产品展示外的任何功能还能运行吗？答： 用户还能看；排除了产品展示，保留分页，交易等还能运行吗？答： 不能，没有任何意义了（书里对亚马逊给出的架构是： 先用服务端渲染把产品渲染好了，然后往同构靠拢实现交易等模块）
3. 对两者都强的例子： codepen，既给用户提供编辑器实时展现自己的代码成果，也给其他用户提供公共目录展示所有成果；这种情况下去除哪个都可以运行，所以网站就不能简单的以docoment还是app区分（书里对codepen给出的架构是： 两个团队，一个服务端，一个客户端）

• 继而得出趋势： 越内容越适合服务端渲染 越功能越适合客户端渲染 两者之间则适合同构

11. 性能

• 团队应该优化的度量标准取决于他们的用例。主页的性能期望与结帐过程的性能目标不一样

微前端利弊

• 短期内，部分模块更新技术栈的成本比整站更新小得多（这也是我最看重的一个优势）

疑问

1. 微前端+拖拉机例子是以业务线（详情，推荐，交易）来分的，那长远看未来，会不会业务线比里头更容易改变？比如会不会出现：直接删除【交易】整个业务比【详情】模块的对应前端技术升级来的更快？

答案： 如何给遗产项目续命，才是我们对微前端最开始的诉求

新理解： 事实上如果所有的 web 技术栈能做到统一，所有 library 的升级都能做到向下兼容，我们确实就不需要微前端了（是不是又可以理解为应对变更的工程解决手段，只不过应对的不是需求变更，而是技术（也是实打实的代码）变更）

得出新的结论

• 业务需求是需求，技术更新迭代的需求以及个人技术提升的需求也是需求，而针对这两种需求的变更，其实都可以用工程的思想解决，无非就是： 高内聚，低耦合，分治
• 这里的技术升级就是一种需求变更，对企业，对个人都需要去应对，微前端的核心目标就出来了