先说说nuxt.js的优势

1）就是我们无需为了路由划分而烦恼，你只需要按照对应的文件夹层级创建 .vue 文件就行；

2）无需考虑数据传输问题，nuxt 会在模板输出之前异步请求数据（需要引入 axios 库），而且对 vuex 有进一步的封装；；

3）内置了 webpack，省去了配置 webpack 的步骤，nuxt 会根据配置打包对应的文件；

4）对seo比较友好，对于普通的vue项目，不会将html的dom暴露在页面中。nuxt就解决这一问题。

不要用Nuxt！ 不要用Nuxt！ 不要用Nuxt！

重要的事说三遍。

Nuxt是我用过最后悔的框架，设计理念高度Template化，有太多太多的黑盒。不出问题则以，出问题非常非常难以debug，哪怕是非常非常小的错误（除了前端page还算能debug以外） ，你甚至无法追踪错误在哪里发生。一切都是配置，包括你写的server端代码都是包在盒子里的，抛出异常？ 不存在的，nuxt把异常直接吞了。对docker的支持非常非常糟糕，因为有太多的配置path，resolved path ...，导致你本地测试没问题，放进docker里就各种问题，往往要手动去改。

所以，使用nuxt带来的那一点点便利，与后期维护的巨大成本完全不成比例。nuxt 的整个design pattern有巨大问题, 耦合性太高。

补充:

实际production中，我这两年用到MVC越来越少了,  思考了一下，从 jQuery 到 express+view engine，然后是 MVC(react/vue/angular) + virtual DOM + packet tools，之后出现了SSR，是不是已经有点开始变味？

最新svelte的崛起，complier的回归，只能说印证了历史呈螺旋上升状的事实。

react hooks的引入，其实早已经不再是单纯MVC了，而基本上进入Reactive Programming范畴。

其实说白了只有一个问题无法回避， 就是performance，virtual DOM、tree shaking、ssr 绕来绕去都是为了改善那几秒钟的loading, 然而只要是打包, 臃肿根本上就是难以避免，框架套框架的加法并不能解决问题本身。所以我不看好vue，当然更不看好nuxt，nuxt可以说本身的设计理念就有巨大问题。

一个高度耦合高度template化的community framework？

现实就是, 版本一迭代, 连官方列表里的module都跑不起来...