开发一个大型后台管理系统，应该选择前后端分离的技术方案吗？

目前在前端领域 angular react vue绝对是三大当红花旦，但是也让无数码农陷入选择困难症，引发了大量无休无止的争论。很多讨论 当事人已经忘记了讨论的初衷和边界，最后陷入无意义的口水战。

一、结合“开发一个大型后台管理系统”这个约束条件 冷静的分析一下该怎么选：

什么是后台管理系统：后台管理系统 这个称呼 意味着这是一个B端系统，可以小到部门级应用（客户投诉登记系统、办公设备台账系统），大一点可以是大集团级核心系统（500强保险公司客服、呼叫中心），可以是ERP、CRM、OA产品（SAP、用友、泛微协同），可以是一个B2C电商的商城后台、支付网关管理控制台，可以是Saas的管理后台（Salesforce、Teambition、Jira），可以大到阿里云控制台。。。

什么是大型：我理解大型系统是指功能模块多、交互复杂，而不是访问量、TPS、数据量大；所以CMS、OA、ERP、CRM、阿里云后台、呼叫中心、各种管理系统 只要功能多都可以称为大型系统，虽然他们体量和交易量可能不在一个量级。 另外大型系统基本等价于“维护周期长 需求不断变更”，这个在后面维护成本部分阐述。

性能考量不是主要决定因素：因为我们这里讨论的是B端系统的前端技术选型，因此我的观点是性能不是主要考虑因素，因为性能瓶颈往往在后端和数据库，其次B端产品不存在爆发性交易量（秒杀 大促 活动），最后B端产品不强调首屏渲染速度。

UI操作效率是最主要考核指标：B端系统产品都是用来干活儿、管理、生产调度的，操作效率和方便性大于天。屏幕空间要充分利用 减少切换跳转弹窗；快捷键效率远高于鼠标；SPA 多页签布局有利于保持工作上下文和状态；必要时可以鼠标右键菜单操作；功能菜单操作提示要清晰易理解 减少培训麻烦；在此基础上 尽量少每一个界面上呈现的信息量 只呈现最少的必要信息 降低用户认知压力；

UI开发效率高维护成本低是关键考量因素：大型系统基本等价于“维护周期长 需求不断变更”，因此在技术选型上必须要求维护成本低、学习成本低、招聘容易、组件化程度高代码简洁。。。

UI颜值美观度不是关键考量方面：界面简洁大方 图表丰富 数据展现清晰，这其实本身就是一种美——朴素实用的美。

浏览器兼容性 看情况：Saas要求兼容性高，内网系统内部系统可以强制统一浏览器。

二、前后端分离对于“大型后台管理系统”弊远远大于利

大型后台管理系统 其实还隐含等价于“业务逻辑复杂”！相对于C端产品，B端产品业务逻辑复杂得多。我不是说B一定比C难做，C有另外的难度（比如用户体验、比如竞品之间的竞争更加激烈、比如并发量挑战、比如做活动的需求频繁。。。）。单说产品核心业务逻辑，B一定是更高的。

复杂业务逻辑的产品 一定不是单靠产品经理、BA或前端设计出来的，也不是不能做，但那样的产品 在业务抽象度、扩展性、实用性方面容易往往存在先天不足（无意引起争论 一家之言）。

解决的办法其实很简单：产品、美工、开发各工种人员密切配合 快速原型 MVP（Minimum Viable Product） 快速迭代 快速试错，

全栈开发的效率 效果 要远远高于前后端分离；

这里说的“效果”指的是趁热打铁和技术主观能动性的效果。

那种“产品画框图 美工做设计稿 前端切图 扔给程序员渲染模板”的传统开发流水线，会彻底拖慢一个业务需求从想法到交付的周期 会彻底割裂整个团队 会遗漏大量的上下文信息 会增加巨大沟通成本 会彻底磨灭项目成员的参与感和对产品的归属感。

画图仔、切图仔和码农 按部就班像流水线拧螺丝一样开发产品，绝对无法创建出一个有灵魂有灵性的产品！

更不用提前后端分离造成的开发、联调、部署、定接口、维护接口的成本提高。

另外前后端分离也不适合项目型公司，因为项目周期有限 分离的团队组建起来 磨合顺畅就很耗时，项目结束后又解散，下个项目重复资源浪费。留守项目的人员配置不齐 导致需求变更和维护问题难以解决。

综上：angular react vue基本意味着前后端分离的开发和部署模式，这已经在根本上决定了它们不适合“大型后台管理系统”，原因 一方面是上面列举的种种弊端，另一方面是大型后台管理系统无法享受到前后端分离的好处：nginx分开部署的优势、专业前端优势（C端产品追求极致的颜值和用户体验）。

既然这么多弊端 又享受不到优势，为什么很多企业（项目）跟风搞前后端分离 跟风上vue react呢？ 答案其实很无奈“简历驱动的开发”、“KPI驱动的技术选型”。

三、切忌“简历驱动的开发”、“KPI驱动的技术选型”

软件开发绝对是个良心活儿，跟医生 教师。。。一样的。

我这几年见到了太多的微型团队（10人以下）搞微服务架构，百万级数据量的大数据项目，以及前后端分离的CMS内容管理系统！

见了太多为了用时髦技术而盲目选型的事情，太多不计后果不计成本的追求新技术来美化自己简历，太多用流行技术名词忽悠自己不懂技术的老板 上司的情况。

你们的良心不会痛吗？

当你在简历上加上了一个个流行技术关键词，然后拍拍屁股离开了一个烂尾的项目 一个预算严重超支的项目 让创业团队多走几年弯路甚至夭折，你的良心和职业素养都破产了！

你正在透支技术人这个工种这个群体的社会声誉。

技术人的天职 本应是把复杂模糊的现实世界问题 建模成清晰逻辑结构化的计算机软硬件，让世界变得更简单高效，如果因为一些奇怪的原因而把简单问题复杂化，那就是背离了这个行业的初衷。

希望越来越多的甲方、非技术出身的高管们明白一个道理：靠谱的人是把解决方案做的很简单以至于明显没有问题，不靠谱的人会把解决方案做的毫无必要的复杂以至于短时间内看不出明显的问题。

前后端分离不是坏的，跟风才是坏的

前后端分离的出现和存在，当然有它的合理性和优势，看看谁创造了它们——谷歌的angular、facebook的react、阿里的antd、饿了么的element、前谷歌程序员尤雨溪创建的vue。

总之就是IT大厂在创造和使用这些技术，这个我就不展开讨论了，超出了我的能力范围。

但是简单看下它们创建产生的背景 当时的初衷 后来的成功案例，不难发现 这里面其实还没有erp crm这种典型的B端大型复杂系统。

所以我建议 至少不要不加思索的就把前端选型的候选人圈定在这三个当红花旦，不要觉得跟着互联网大厂走就一定不会错。

彼之良药汝之砒霜，你要搞清楚你自己是什么样的定位！

互联网大厂 独角兽 前沿风口上的明星产品很多情况下都是资本游戏 烧着风投的钱 靠补贴做活动 砸广告费引流做出来的数据 把估值做高找下一轮风投接盘。如果你是这种情况 那没的说，尽管选最好最贵对标一线大厂技术栈 甚至人都是各大厂挖来的。

如果你们是做项目赚辛苦钱 或自己投资研发产品，在传统方向在产业互联网精耕细作 慢慢摸索培育市场 不在风口不受风投追捧的，那我觉得你们需要务实一些。

我建议各位本着务实和诚实的态度、职业精神操守，结合自己公司 团队 项目 业务需求，选择最适合自己的技术栈。

问题还是回到“开发一个大型后台管理系统，应该选择前后端分离的技术方案吗”？

我对java开发为主的公司和团队 推荐一个东西：ZK（The leading enterprise Ajax framework） 纯java的企业级前端框架。

https://blog.csdn.net/daquan198163/article/details/9304897 https://www.zkoss.org/

(转载知乎)