@riverxs
1，我并不主张 redux 把所有 state 都放到 store 里面，相反我更希望把组件紧紧关联的自我状态交由组件自己去管理。我所纠结地在于，一个组件在当前页面被用户操作之后，组件状态改变了，更换页面回来会发现 state 居然被清空了。
从用户角度来说，这是并不友好的。我原本用户操作的状态(比如一个 tab 标签选择某一个高亮)，居然跳回页面就恢复原样了，这是反直觉的。如果需要实现 keep-alive，你就必须通过一些状态管理库来管理 store 来同步状态。这当然是最佳实践而且优雅至极的方式了，但是对于一些 CRUD 项目来说，十几个 Tab 标签页，五六个 table 并且带有过滤高亮用户点击高亮行功能，渲染起码 2 秒的三四个 echarts 实例，如果你要在页面跳转回来渲染的成本需要多高？就不说这个渲染的问题，就算你能把所有状态都保存下来，做好了各种数据同步的工作->重新获取 store 值->判断是否需要渲染->在组件 mount 的时候做一些初始化的工作，我绝对相信这个性能会大大打折扣，甚至比不上 jQuery 时代的页面，舍本逐末了。
keep-alive 有缓存页面太多导致卡顿的缺点，redux 也有不缓存页面节省空间的优点。但是我觉得不能认为因为 react 可以通过数据管理库来管理状态，从而忽略掉 keep-alive 这一方便开发者的特性。无论是小的 CRUD 项目，还是大型的 ERP 企业应用，keep-alive 这个特性绝对是值得关注的。就我所知的确有开源的 react-keeper，但这并不是官方组件，说不定哪天跟不上 react-router 的搭配，从开发者角度来看并不令人信任。
2，的确是我主观了，各有所好吧
3，都是参考 flux 思想的，Vuex 学习成本的确更低
4，性能两者都是没有明显差距的，能拉开开发效率和性能的恰恰路由、状态管理库这些周边生态。一个开发者如果以相同时间和精力去做一个项目，我相信 Vue 绝对是一把瑞士军刀，无论从:sync 这类语法糖，还是周边生态的完备和用户体验良好，更剩于 react。
5，React 自由发挥空间大，这意味着开发者需要花费时间去精心搭配工具链，如果不巧踩坑了(参考 RR4，这个发布多久还像测试版)，又需要花费精力去修复。自由也是有代价的，也正因为这些代价难免让人感受到 React 不安全，从项目技术稳妥和效率上来看，Vue 无疑是更佳。

@riverxs 不管是性能还是效率还是周边，我感觉 Vue 更贴近开发者的角度，没有那么多理论的东西。
我指出来的这些应该不只是我个人的痛点，也是很多开发者的痛点，相比之下，我找不出为什么放着 vue 不用跑去用 react 的理由

@98jiang 不是我。。亲戚从乡下回来，直接毫无生息就过来了

@noNOno @marrysail 服务器我感觉还算是很高配的，128G 内存，而且处理器也不差。主要是并发量不高，一天能有一次查询就算好了，查询条件大部分都是 where，很少 join，最多就是 join 一个常量配置表，需求也比较稳定，就是想快速完成这些项目，否则现在弄起来好费时间

@jitongxi 这种实现方式的确很古老。。但是开发效率至少，搞好之后再改动的可能很小，相当于是一次性项目开发吧，我不太想一步步优雅的弄这些重复的生成 ORM，Mapper，Controller，只想开发效率至上

@lichao Java 的 ORM 还有 MyBatis 都很好，就是感觉不如直接撸 SQL 语句来得快，总感觉大部分时间都在处理 Controller 和 Mapper 之间的关系了，想早点下班，唉

@dtgio 在接口出问题的时候，会产生撕 b
你这个参数不对啊？
你这个 Url 大小写问题啊？
你这个一直 pending 不返回啊？

如果都是你一个人，emmm，自己默默解决掉