前后端分离的开发模式，这两年确实被炒得如火如荼，导致这个话题也成了面试极其爱问的一个问题，尤其是换工作、跳槽，之前不管你是做后端，还是前端，都可能会涉及。
面试官常问：
- 诶？你对前后端分离有什么理解啊？
- 你觉得一个项目应该如何实施前后端分离呢？
很明显，这是一个开放性问题，但是却能考察出选手们技术关注点的层级。
其实在回答这个问题时，尤其程序员，一谈到这个问题，上来就一头扎进了某项具体的技术中去了，比如什么：Ajax异步请求、 Vue组件化框架、 RESTFul接口规范、 API接口数据约定、 Mock平台和数据等等。
恕我直言，这估计很难成为面试官内心想要的答案。
因为站在面试官的角度，这个问题大家如果仅仅以某项具体技术、框架来切入，他会觉得你的理解其实很局限。因为很有可能你只知道有前后端分离这个概念，却不知道为什么要做前后端分离这件事情。这尤其对培训班出来的小伙伴，如果只谈到这个深度，就非常危险了。
而且社会上很多公司、团队的一个误区就是：为了做前后端分离而做前后端分离。
从历史渊源说起
以前很长的一段时间里，在一个搞开发的公司里，其实后端工程师是比较有 “门面” 的，往往也是项目和公司的核心团队。这种观念甚至影响了现在很多的应届生求职，都挤破头想去后端开发岗。
那个时候前端开发肯定也是有，但直言不讳，那时候的前端开发人员压根就没什么话语权和公司地位，仅仅是一小撮人散步在团队的小角落，甚至在很多团队里，前端开发都是后端工程师兼任的。
你回想一下，那个年代用的JSP技术不就是这个样子吗？我们就以JSP举例。JSP就是前、后端耦合在一起混着做，套个模板可以把大家弄得死去活来。
这种开发模式在以前那个互联网服务还不是那么繁荣，Web化趋势还不是那么明显的年代，发挥着巨大的作用，大家用得还算开心，毕竟页面不复杂嘛。
但随着社会信息化程度加深，各种各样服务都Web化以后，很多前端展示的东西都变得复杂起来。不信你去数一数淘宝这种网站的页面树，简直太复杂！这时像JSP这种模板技术就没办法高效开发。
究其本质原因，还是因为前端这时候并没有工程化、模块化和可复用化。但那时候的后端不一样，一个Spring这种工程化的开发框架就可以撑起半边天！
所以你想想，这时候开发必然会出现各种不协调、低效率、甚至推诿扯皮的问题。所以从公司项目管理的角度来看，这种开发方式就会非常影响开发效率，所以项目管理者们开始想办法来解决这个问题。
一条永恒的法则！
所以你们说应该如何解决上面的问题呢？
解耦呗！
大家有没有发现，在软件领域，任何复杂问题面前，高内聚、低耦合这个法则几乎都能见效！
所以：
- 前、后端的事情分开来做吧！
- 我们要把前端开发的责任从后端工程师身上拿掉！
- 我们要给前端开发工程师一个单独的岗位和责任领域！
- 我们要给前端开发者们正名！
- 我们不能让前端开发总是用野生的模式开发，不能一天到晚到处copy html片段，js片段来人肉试错！
- 前端开发也需要工程化、项目化的思维来做！
所以这才是前后端分离开发模式最开始的来源。
说来说去，前后端分离与否，它本身并不是一个技术问题，而是一个项目管理的问题。
自此开始，前端独立出来了，单独行动了。那技术上的问题又怎么解决呢？
组件化框架革了谁的命？
自学过前端开发的小伙伴可能会有一种感觉就是：我去，前端这玩意怎么这么琐碎和玄学！知识非常零碎、不易掌握、学了就忘！
很多人学习、甚至工作了都还是东拼西凑、复制粘贴，copy代码段、东拼西凑，靠往上堆积来完成需要的页面和效果。
你会感觉前端这玩意它就是没有Java后端开发这么有逻辑、易管理、可复用！
所以直到像 Vue.js， React.js等这些前端组件化框架的出现，它才从本质上颠覆了前端开发的游戏规则！我们称它前端组件化框架，但我们更愿意叫它前端工程化框架。因为自此开始，大家都遵循一套体系来进行约束性开发，前端开发迈向了工程化、组件化、迭代化之路！
而且前端代码也更好复用了。自从有了 Vue.js等这种组件化框架的出现，别人写的现成按钮、菜单、布局，我们直接拿过来用得不是挺爽嘛！典型的比如像饿了么的 ElementUI，以及蚂蚁金服的 AntDesignUI，这搁以前哪能做到。
而且随着 Node的出现，前端开发可以借助 Node来开发各种各样的工具来辅助高效的开发，比如各种包管理器、预编译工具等等，这也是前端开发步入工程化的一个重要的方面
前后端分离如何落地？
换句话说：到底怎样做才是一个比较优雅的前后端分离呢？
一个正常的软件开发可以简化成四大步：设计、开发、测试、部署，所以真正的前后端分离应该渗透到每个步骤中去。
第一个阶段：设计阶段
设计的第一个层面当然是系统设计：后端系统设计较好理解，主要是系统架构、数据库、中间件、缓存等，主要考虑性能、容量、扩展性、维护性；那前端也应如此，假如网站非常复杂，页面极其多，这时前端项目架构也需要做好规划，尽量满足长期演进、可迭代的目标。
设计的第二个层面就是接口设计：前后端系统通过接口进行交互，这时模型（ Model）层面的接口约定极其重要，包括：接口请求方式、数据类型、数据格式等。开发前，前后端双方评审到位，都认可之后方可进行下一步开发，否则未来在开发过程中，前、后端开发工程师永远在为了某个破接口扯来扯去！
第二个阶段：开发阶段
各自按照事先评审好的接口独立开发，互相无需扯皮。
现如今，前端在诸如 Vue、 React等当下火热的组件化框架的加持下，的确可以独立驱动页面，数据则从事先规划好的 Mock服务器去拿，完全不依赖于后端。
后端则只需要把接口写好，按照先前评审好的约定提供数据。不管后端用Java的 SpringBoot，PHP的 Laravel，亦或是Python的 Django、 Flask，这些都跟前端没关系。而且后端一套接口可以提供给多种类型的前端使用，譬如：Web网页、手机APP、微信小程序等等。
第三个阶段：测试阶段
基本上要保证的是，前后端独立可测试。前端主要就是页面、跳转、展示、输入、传参、响应数据的展示等；后端主要则考察数据格式、校验、异常情况、数据一致性甚至一些权限问题。
最后一个阶段：上线部署
前后端项目独立部署，这个很关键！在以前的JSP模板时代，前端的html页面、css样式、js效果均由后台来驱动。那个时候所谓的项目部署上线，其实指的也就是后端项目的部署，前端“所谓的”发版本，还是得求着后端来做的。
前后端分离后责任就清晰了，前端项目单独部署。前后端发布上线完全独立，双方可以按照各自的版本规划来发布版本，前端发版本不再受后端约束，后端发版本前端也可以不知道，互相透明了。
还有一个必须提的就是，很多公司里，后端项目都是通过诸如 Jenkins等 CI系统去做持续发布，一键部署，同理前端项目也应该拥有自己的CI系统。
这玩意真那么邪乎？
最后一个问题： 前后端分离吹得这么邪乎，它真的就没有缺点吗？
这个问题就要回归文章开始的讨论了，即：为什么会有前后端分离这件事情的出现。
怕就怕很多公司为了前后端分离而做前后端分离。前后端分离需要成本！尤其当你想做一个彻彻底底的前后端分离，不管是人力成本、开发成本、工具成本、还是部署成本，都是不小的。
不顾实际需求，强行前后端分离开发只会带来麻烦，因为只要落地过程中某一步做得不彻底，就会带来很多负担！毕竟并不是所有项目都适合前后端分离！
还是那句话，前后端分离与否，它本身不是一个技术问题，而是一个项目管理的问题！
**本文旨在梳理整个Java后端的学习路线，所用图片/思路来自b站up主codeSheep，羊哥搭建的网站也有详细的学习路线：原文链接
