第一个问题：可以。

第二个问题：见 https://caniuse.com/#feat=async-functions。

@aoscici2000 #14 Vue 官方文档：

注意对象（ Vue.set( ) 的 target 参数）不能是 Vue 实例，或者 Vue 实例的根数据对象。

1 是 this.catalogs 的属性名。由于它是个数组，所以属性名就是数字的形式，也就是数组下标。

从贴出来的代码上看，没问题。我现在只能怀疑是你的 Array.prototype.concat 有问题。

@aoscici2000 #12 this.$set( ) 不能这么用，应该是：
this.$set(this.catalogs, 1, resp.data.data[0])
// ...

刚注意到我上面说的不准确，调用 catalogs 的变异方法或直接对 catalogs 赋值是可以触发响应式更新的，只有直接访问数组元素内容时才不行。

但不管怎样 this.$set( ) 不应当失败。还是需要你发出来代码看一下。

如果确定这个函数有返回，会写，主要是为了避免自己太蠢 return 了错误的数据类型。

当然有时候还是会犯懒，如果函数体很短就交给 TSC 自动推断了（

如果 catalogs 是异步数据，那么在 v-for 执行时数组内容为空，Vue 无法绑定 watcher，自然也不能实现响应式更新。

解决办法是，异步请求返回 catalogs 内容后，用 this.$set( ) 或者 Vue.set( ) 写入数据到 catalogs 中，强制 Vue 刷新 watcher。

看你的目标用户环境是什么。px2rem 就是对 vw 的模拟，如果你的目标环境都兼容现代浏览器特性，那直接用 vw 就好，否则你也没什么太好的办法。

@MonoLogueChi #1 PnP ？虽然这货现在还不成熟。Yarn 的 CDN 相比 NPM Registry 似乎对大陆友好那么一点。另外，Yarn 的 API 用起来比 NPM 更自然。

@version #29 正是为了解决「后人不更新维护」的问题，才更有必要使用 Vue CLI。企业内部不愿维护工程配置有多种原因，成本正是其中之一，毕竟工程配置是很难创造业务价值的。Vue CLI 3 不使用 eject 也是为了尽可能保证用户的工程配置总可以伴随 Vue CLI 的更新而更新。这样，后人只需要更新 Vue CLI 就可以引入 Vue 应用工程的最佳实践，有何不好呢？

@tuchg #6 我的话，常用「库」的常用 API 已经背下来了，需要查的时候去官网或者 devdocs.io ，对 Ctrl + Q 其实没什么需求。

另外我意识到一件事，你用 JDK 对比前端「库」（比如 Vue ）是不合适的。JDK 对于 Java 开发来说属于环境，对应到前端的应该是 DOM、Node 这类东西。而且它们的 API 文档 JetBrains IDE 是内置的。

@version #16 不会 Webpack 就不能实现工程自动化了？没搭过研究过 Webpack 就不能懂模块加载机制了？不懂 Webpack 就不能写出厉害的、兼容性很好的代码了？没有 Webpack 浏览器就不能好好加载资源了？

朋友，这个世界很大。

另外，为什么要折腾 cookie ？

支持嵌套弹窗的应该都能做到这种效果。推荐插件，谁的插件？ jQuery ？ ExtJS ？ Vue ？ React ？

只能说 JS 圈少有这种习惯（把文档以注释的形式写的源码里），毕竟 JS 一开始都不支持「库」的概念，而且交付出去的代码量越少越好（因为会影响到客户端加载性能）。这跟从窄带网络时代过来的、一旦部署到本地就无需二次加载的 JDK 自然不同。

Java 能直接查文档难道不是因为 JDK 里的注释？

Vue CLI 3，因为懒。我是写应用的，又不是写工程配置的。以后有更好的 Node 工具链方案，我只管升级 Vue CLI 就得了，Webpack 的具体配置爱啥啥，多省心。不过话说回来，如果以配置 Webpack 为乐趣的话，手写 Webpack 配置也没啥不好，反正（目前） Vue CLI 的真身就是 Webpack。

不过想快速起一些技术验证工程的时候，我会使用 Parcel。

Angular 是一个应用框架。
React 是一个视图层渲染工具库。
Vue （可以）是一个视图层渲染框架。
（以上按字母序排列）

对，你下单时最新的是什么版本，你就可以一直用什么版本。

@lzj307077687 #33 这个类比绝了