@xiaody A/+ 告诉我们一个 Promise 有且仅有三种状态，这就是构造函数的内容。。其次，Promise 所有的静态方法都依赖于构造函数的实现（一个特殊的语法糖），因为所有的静态方法都构造并返回一个 Promise，换而言之，构造函数本身就会影响所有静态方法的实现。

@libook 感谢回复，我同意你的观点，A/+ 可以视为 ES Promise 的子集，目前苦恼的是莫得对针对 ES Promise 的完备性测试，以区分两者的差异。

@autoxbc core-js 太依赖 host 了（涉及 doceument 和 process 等），确实实现了 ES Promise，但不是对规范的完全翻译（比如考虑不同 host 的兼容性），我更倾向于 bluebird 或 q 等基于 UTDD 的实现。Promises/A+ 在我看来时 ES Promise 的子集，但我目前能获取的测试包仅能提供基于 Promises/A+ 的测试，所以才想要了解两者的差异，完善给予 ES Promise 测试。

此问题已解决。

借鉴了 `Vue.js` 源码工程化方案和 `TypeScript` 的官方推荐后，使用改进版的方案 1+，即使用 `rollup.js & Babel` 生态支持 `TypeScript` 语法和生成 JS 文件，使用 `tsc` 检查类型和生成声明文件。

PS： 关于方案 2 的 `transformer` 可以加强 `AST` 的认知和 `Babel` 生态的了解。

@MrYELiex 本末倒置，规范才是根本，就好像先有构造函数才有对象，JS / TS 之类的语言都是根据 ES 规范这个构造函数来实例化的， 而且 TS 这是伪私有变量，肯定要有一个真正实现私有的变量的提案。

@anguiao 感谢回复，这个更新我知道，默认安装 LTS 版本已经就是 v4+了， `#` 前缀一直可以使用，问题主要在于和 `static` 的共同工作，以及 AST 层面的 `trnasformer` 实现。

推荐使用 react 和 angular 。

1. $attrs;
2. provide.

大型项目的边界视公司规模和项目需求而定，不太好区分。
不过你有这种观点显然已经熟练掌握了两种不同的技术，并做了测试用例具体比较了驱动性能。
可不可以给出你做驱动性能的测试用例差异表格，这样比较直观，也更能体现你的观点的说服力。
如果真的性能不行，我赶紧叫公司换技术。

缓存算法具体内容补充：
vue@2：使用数据结构数组（顺序）+对象（读写） [有点像散列表+双向链表的思路] ；
vue@3：独属于 JS 语言的完美实现：ES6 数据结构，Map 的黑魔法 [虽然迭代器特性仅适用于某些场景，但这个很值得借鉴，本人扫盲成功] 。

+ 折半（二分）查找（序列子分支算法优化，可以先了解这个的原理，然后尝试实现完整算法）。

@lqfxz520 学习就是将知识固化为常识的过程，只要突破舒适区就是进步，咱慢慢来。算法据说是编程基础，可我就是学不懂，同病相怜啊。Fighting ！

@waiaan 您是指 vue@2 的双指针重排吗？我差点忘了这个， 不过这个比较复杂且全面，我感觉笔试题应该不考这个吧，感觉这个算法不够普遍且难度颇高。

此问题已解决，谢谢大佬们的回答。

@zzk1989 膜拜大佬，有点硬核，目前本人技术仅限于卑微 APIer，会努力尝试新 API，等正式版稳定会慢慢尝试看源码，看源码确实比较有效和正确。

离开列表组件之后，列表组件会被销毁，在详情组件回来，本来就会触发生命周期钩子（一般是 created 或 mounted ）重新请求最新的数据。
如果没有执行生命周期钩子，说明有人用了 <keep-alive /> 对列表组件进行了缓存，事实上一般这种数据量较大的列表组件确实会进行组件缓存的，但也可以根据需求来灵活配置缓存策略。
组件缓存是涉及应用级别状态管理，可以结合 Vuex + 路由导航守卫根据需求自由配置，Vuex 负责管理全局的组件状态，路由导航守卫定制缓存方案。

如果是移动虚拟节点，那么节点就没必要比较和打补丁更新，可以复用，直接 return 跳出比较 patchVode() 方法。

当你觉得设计不好看的时候，当你觉得组件太少的时候，当你觉得生态不好的时候，你可以自己封装发布一个组件库，一来好看，二来组件内容充实，三来丰富生态，源于开源项目、服务于开源工作者，一举三得。我们不讨论组件库，我们只使用组件库，或者实现组件库。Vue@3 来了，生态跟不上，我还是去用 React 了。