到底什么是前后端分离？
45 个回答
前后端分离是个架构设计问题。
所谓架构设计，实际上是如何合理的对现实的人力架构进行系统映射，以便最大限度的压榨整个公司（组织）的运行效率（万恶的资本家）。
上面这句话是我对康威定律的理解。
康威定律：
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)
中文直译大概的意思就是：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。注意康威说这句话的年份，灯塔国确实不是靠吹的。
我们先看看一个 Web 系统，在前后端不分离时架构设计是什么样的
用户在浏览器上发送请求，服务器端接收到请求，根据 Header 中的 token 进行用户鉴权，从数据库取出数据，处理后将结果数据填入 HTML 模板，返回给浏览器，浏览器将 HTML 展现给用户。
有什么问题？
问题点在图右边那位全寨（栈）开发人员！
他她既要会数据库开发（SQL）、又要会服务器端开发（Java、C#），又要会前端开发（HTML、CSS、JS）。现实告诉我们，百样通往往不如一样精，什么都会的人往往哪一样都干不好。是否可以按照前端后端进行人员职责区分呢？如果进行职责区分，分成前端开发和后端开发，但由于程序全在一个服务里，不同职责开发人员彼此间的交流、代码管理就会成为一个大问题，也就是交流成本膨胀的问题了。
那么，有什么办法可以让前端和后端开发只做自己擅长的事情，并尽量减少交流成本呢？
这就是前后端分离了。记住，分离的是人员职责，人员职责分离，所以架构也发生变化了。
现在 Web 服务器不再处理任何业务，它接收到请求后，经过转换，发送给各个相关后端服务器，将各个后端服务器返回的，处理过的业务数据填入 HTML 模板，最后发送给浏览器。Web 服务器和后端服务器间，可以选用任何你觉得合适的通信手段，可以是 REST，可以是 RPC，选用什么样的通信手段，这是另一个议题了。
这样，前端人员和后端人员约定好接口后，前端人员彻底不用再关心业务处理是怎么回事，他只需要把界面做好就可以了，后端人员也不用再关系前端界面是什么样的，他只需要做好业务逻辑处理即可。服务的切离，代码管理，服务部署也都独立出来分别管理，系统的灵活性也获得了极大的提升。
注意，这不是个微服务架构，那是另外一个议题了
总结，任何系统架构设计，实际上是对组织结构在系统上进行映射，前后端分离，就是在对前端开发人员和后端开发人员的工作进行解耦，尽量减少他她们之间的交流成本，帮助他她们更能专注于自己擅长的工作。
最后是几个常见误解的说明：
1、前后端分离是说浏览器和后端服务分离吗？
不是，前后端分离里的前端不是浏览器，指的是生成 HTML 的那个服务，它可以是一个仅仅生成 HTML 的 Web 服务器，也可以是在浏览器中通过 JS 动态生成 HTML 的 单页应用。实践中，有实力的团队往往在实现前后端分离里时，前端选用 node 服务器，后端选用 C#、Java 等（排名不分先后）
2、前后端分离是种技术吗？
不是，前后端分离是种架构模式，或者说是最佳实践。所谓模式就是大家这么用了觉得不错，你可以直接抄来用的固定套路。
3、前后端分离是最佳实践吗？
看你团队和项目的情况，如果是短平快的小项目，真的没必要。如果是面向简历开发，那绝对在任何时候都应该使用前后端分离这种架构。
前后端分离的"前"特指浏览器端(或客户端)。
Java服务器端初学者最容易引起误解的一个概念就是: JSP是前端技术。
JSP一定一定一定要知道全称：Java Server Page。是运行在服务器端JVM之上Servlet容器里的，只是执行的结果是HTML，响应给浏览器。
Java EE先有的Servlet，那时候已经有了ASP(同样要知道是Active Server Page的意思)。
由于要在Servlet里面拼大量的HTML代码，所以Java规范学习了ASP，提出JSP。Servlet是Java代码里混入HTML，JSP是HTML代码里混入Java。
浏览器根本不关心服务器端是JSP、ASP、PHP，或者还是原始的Servlet，或是静态服务器上的HTML，只要返回的是合法的HTML就可以。
所以，把JSP中静态的HTML部分拿出来，变成简单的HTML文件，放在HTTP服务器上，浏览器只要获取到这些HTML就可以了。动态的数据部分用HTML里的JS通过AJAX的方式从服务器端获取，然后动态操作Dom，完成动态内容的展示。这样前后端就分离了。
上面的内容回答的是问题描述中的第一个子问题。问题描述里的后两个子问题应该这样理解：
2.静态资源和数据接口被部署在两个不同的服务上就算前后端分离？
静态资源和服务(实现接口的业务逻辑)，在开发阶段就分离开发，而部署阶段分离部署在不同服务器上，算是严格意义上的前后端分离。
有些小型项目，开发阶段没有分离开发，也就是说前后端代码在一个Project里。在部署阶段也没有分离，例如静态资源还是放在Tomcat里。这些情况，到底算不算前后端分离，关键是是否"严格"看待。
3.接第二个问题，如果静态资源(html模板)是jsp，而jsp的所有动态数据均来自另一个服务，那这算不算前后端分离？
静态资源是JSP这个观点就是错误的，不做再次解释。JSP是运行在Server上的，动态获取另一个Server上的数据，这是服务器和服务器之间的调用，只是两台服务器的相互角色和分工不同。JSP所在的服务器被称为Consumer(消费者，也就是服务的使用者)，另一台提供数据的服务器被称为Producer(生产者，也就是服务的提供者)。
如果上面为JSP提供数据的服务又调用了第三个服务的接口获取数据，那么就又产生了新的Consumer和Producer关系。
@mrbook 看这个答案
可以看看这篇博客！
这里是经常容易被混淆的一些概念。
在说前后端分离之前，要先弄清楚：
1。什么是前端？
2。什么是后端？
3。什么前后端不分离？
4。什么是动态数据？
5。什么是静态文件？
6。什么是动静分离？
然后，什么是前后端分离就可以很清楚了。
所以，先来看第一个问题：什么是前端？
这又可以分解成几个小问题。
1。JS是前端么？
2。只要用JS写的，都是前端么？
3。只要是前端工程师写的，都是前端么？
4。大前端就是指的用JS语言写的前端，哪怕它是运行在服务器那一端么？
5。App算前端么？
6。Html+CSS算前端么？
7。小程序算前端么？
8。ReactNative算前端么？
这些问题其实会困扰很多人，每一个人的想法也是不一样的。
通常情况下，我们说的前端，都是指浏览器这一端，浏览器这一端，又在通常情况下，都是用JS来实现的，所以又会引申为，用JS写的大部分程序都是前端，包括App，小程序，H5等。而NodeJS出现之后，用NodeJS写的后端部分，也会被人归类为前端，为了区分之前的前端，就给他们起了一个名字，叫做“大前端”。
但，这种以语言为分界点去区分前后端，真的合理么？
在过去，我们是不分前后端的，无论是Java还是JS，全都是一个人来写。
倒底是什么原因让我们开始区分前后端了？
第一个，是可以并行开发。前后端的进度互不影响，在过去，前后端不分离的情况下，前端的工作量相对较少，一个前端可以对四个后端。 可以理解为，前端花了一周时间写好了静态页面，只需要调几个Ajax接口，不需要路由，也不需要渲染，所以他可以把时间继续在下一个项目里。
第二个，是成本问题。在过去，后端的成本还是比前端要高一些。同样的工作，如果能拆给两个人做，一个成本高一点，一个成本低一点，能接受。
第三个，CSS太难了。JS还好，和后端语言在对技能的训练上相差不大，可是。。CSS是什么鬼？记住那么多的属性，和Hash算法有关系吗？
所以才分成了前后端，而Html+CSS+JS，都是在浏览器端执行，统一称之为前端。
而Java，C，Python，PHP这些可以运行在服务器端的，统一称之为后端。
所以前后端的定义，不应该是以语言来定义，而是应该以它的运行环境，如果是在服务器端，就应该被称之为后端，代表着你看不见，摸不着。而如果运行在用户端，就应该被称之为前端，代表你是可以看得到的。
按照这种说法，前端和后端就分的很清楚了。
我们接下来再看，什么叫前后端不分离。
在Android和IOS没有出现的年代，还有一种流行的说法，叫做C/S和B/S架构。现在已经很少有人提了，如果你知道，这又是一个暴露年龄的名词。
C/S架构，指的就是Client-Server，意思就是在桌面程序上，有一个客户端，然后远程连接服务器端，用Socket或者是Http传输数据。
而B/S架构，就是指通过浏览器访问，不用提前安装一个客户端。
B/S架构，曾一度被认为是C/S架构的替代者，好处就是无须安装，简单方便，研发速度也快。
在那个时候，JSP，ASP，PHP还被称为三驾马车。
那个时候的写法，就是后端去控制一切。 http://game.ptteng.com 是我很久之前写的一个前后端不分离的网站，右键的话，可以看到是一个完整的Html页。
这是什么意思呢？就是指，浏览器访问的是一个完整的Html网页，而这个网页呢，并不是一个静态的网页，写好在服务器上的，而是应用程序从数据库里取数据生成的，动态网页。
所以，前后端不分离的交互方式很简单，就是浏览器发请求，服务器端给出一个完整的网页，浏览器再发请求，服务器端再给出一个完整的网页。
坏处很明显，传输的重复数据比较多，网络又会有延迟。所以有没有办法，只传送必要的数据？
这是Ajax的起源。
Ajax就是只传递数据，不传递整个网页。这也是被用来在翻页，注册，发送验证码等场景，但也仅仅止布于此了。
怎么样提升访问的性能，更多的人用的是网页静态化的技术。
就是把所有的动态数据都提前生成很多很多静态的Html网页，这样就避免了从数据库里取数据的时间。
这种方式本来不会发生变化，大家都习惯了这种做法。
突然有一天，苹果说我们发布了Iphone。这个Iphone居然可以让程序运行在手机上。
很有一种C/S架构的感觉。
只是过去的C/S架构并没有大规模的应用在互联网上，多数上传统行业，互联网还是前后端不分离的多一些。
可是后端在写这些被称之为客户端的程序，就觉得太爽了。
过去还要套页面，还要控制跳转，现在呢？
面向Api编程啊，只需要告诉我Api是什么，我的每一个Api都是独立的，互相之间没有依赖。
App自己做控制，做缓存，做跳转，做交互。
后端神马都不用管，只需要保证自己的Api接口是好的。Postman很好用啊。还能自我验证。
但是不爽的在哪里？
就是针对客户端会有一个ApiServer，然后针对网页，还会有一个Home。
两个功能经常会一致，但是后端人员要写两套代码。一套是生成Json的，一套是生成Html网页的。
前端JS也很羡慕客户端的开发人员啊。过去前端就是一个打边角料的角色，只能写写静态文件，看着后端去把页面套的错误百出，偶尔写个校验，发送一个请求。
可是人家客户端！跟后端就没什么废话说，你只需要把API保证正确，剩下的全部我来。
两者之间的交互简单方便，快捷省力。多好的方式？
所以网页能否和客户端一样，也把决策权拿自己手里？
实际上是可以的啊。Angular就这么干了！
这就是SPA的含义之一，总之，到这个时候，前后端分离的意义才展示出来。
再说什么叫做动静分离，这里还牵涉到一个叫做打版本的概念。
一般而言，会分成开发，测试和线上的环境。
在SVN的年代，分成Trunk，Branches和Tags。
Tag，就是一个版本的快照。
为什么要有版本的快照？是希望能够在发生错误的时候回滚。
所以在前后端不分离的时候，如果发现网页上有一个错别字，怎么办？
不好意思，拉一个分支出来，重新打Tag，前端后端的代码一起打。不允许你手动修改。
但是后端的发布是需要重启服务的啊。
为嘛我改一个错别字就需要重启服务？有没有办法让后端和前端不在一起部署？
互相独立？前端你写错字了，你自己来，反正 你又不需要重启？
这就是动静分离的起源。
把动态程序和静态程序分开，大家互相不影响，各自部署分开。
现在，你能区分出来这些概念了吗?
前后端分离不只是开发模式，而是web应用的一种架构模式。在开发阶段，前后端工程师约定好数据交互接口，实现并行开发和测试。在运行阶段前后端分离模式需要对web应用进行分离部署，前后端之前使用HTTP或者其他协议进行交互请求。
而作为一种架构模式，我们在实施的过程中主要对以下四个方面来进行比较和重新认识。
前端后分离我们从四个方面来理解一下：
- 交互形式
- 代码组织方式
- 开发模式
- 数据接口规范流程
一、交互模式
在前后端分离架构中，后端只需要负责按照约定的数据格式向前端提供可调用的API服务即可。前后端之间通过HTTP请求进行交互，前端获取到数据后，进行页面的组装和渲染，最终返回给浏览器。
二、代码组织方式
在传统架构模式中，前后端代码存放于同一个代码库中，甚至是同一工程目录下。页面中还夹杂着后端代码。前后端工程师进行开发时，都必须把整个项目导入到开发工具中。
而前后端分离模式在代码组织形式上有以下两种:
- 半分离
前后端共用一个代码库，但是代码分别存放在两个工程中。后端不关心或很少 关心前端元素的输出情况，前端不能独立进行开发和测试，项目中缺乏前后端 交互的测试用例。 - 分离
前后端代码库分离，前端代码中有可以进行Mock测试(通过构造虚拟测试对 象以简化测试环境的方法)的伪后端，能支持前端的独立开发和测试。而后端 代码中除了功能实现外，还有着详细的测试用例，以保证API的可用性，降低 集成风险。
三、开发模式
我们之前的架构属于传统的MVC架构，整体没有进行前后端分离，在项目的开发阶段，前端工程师负责编写HTML，完成前端的页面设计并套页面，然后再使用模板技术将写好的前端代码转换为Smarty脚本，同时内嵌一些后端提供的模板变量和一些逻辑操作。应用运行期，将全部代码进行打包，和后端代码部署到同一服务器上，同时会进行简单的动静态分离部署。
此时，应用的开发流程如下图所示。
而在实现前后端分离架构之后，前端工程师只需要编写HTML、js、CSS等前端资源，然后通 过HTTP请求调用后端提供的服务即可。除了开发期的分离，在运行期前后端资源也 会进行分离部署。
前后端分离之后，开发流程将如下图所示。
通过上面的两幅流程图，不难发现，在开发模式上，前后段分离不仅仅只是工程师的分工开发，更重要的意义在于实现了前后端的并行开发，简化了开发流程。
四、数据结构规范流程
在开发期间前后端共同商定好数据接口的交互形式和数据格式。然后实现前后端的并行开发，其中前端工程师再开发完成之后可以独自进行mock测试，而后端也可以使用接口测试平台进行接口自测，然后前后端一起进行功能联调并校验格式，最终进行自动化测试。
五、分离的四个好处
前后端分离模式和传统的web应用架构相比有很大的不同，到底分还是不分，这还真是个问题。
从目前应用软件开发的发展趋势来看，主要有两方面需要注意：
- 越来越注重用户体验，随着互联网的发展，开始多终端化。
- 大型应用架构模式正在向云化、微服务化发展。
我们主要通过前后端分离架构，为我们带来以下四个方面的提升：
- 为优质产品打造精益团队
通过将开发团队前后端分离化，让前后端工程师只需要专注于前端或后端的开发工作，是的前后端工程师实现自治，培养其独特的技术特性，然后构建出一个全栈式的精益开发团队。 - 提升开发效率
前后端分离以后，可以实现前后端代码的解耦，只要前后端沟通约定好应用所需接口以及接口参数，便可以开始并行开发，无需等待对方的开发工作结束。与此同时，即使需求发生变更，只要接口与数据格式不变，后端开发人员就不需要修改代码，只要前端进行变动即可。如此一来整个应用的开发效率必然会有质的提升。 - 完美应对复杂多变的前端需求
如果开发团队能完成前后端分离的转型，打造优秀的前后端团队，开发独立化，让开发人员做到专注专精，开发能力必然会有所提升，能够完美应对各种复杂多变的前端需求。 - 增强代码可维护性
前后端分离后，应用的代码不再是前后端混合，只有在运行期才会有调用依赖关系。
应用代码将会变得整洁清晰，不论是代码阅读还是代码维护都会比以前轻松。
六、前后端分离的场景
任何一项技术以及架构都不是适用于任何场景，前后端分离同样也是如此。虽然前后端分离架构能带来许多的好处，但前提是建立在开发团队合适的基础上的。
而我们百度网盘就属于那种：
- 页面布局复杂，使用了主题和样式。
- 需要有较高的页面渲染效果
- 前端页面中包含复杂业务逻辑
- 页面需要渲染的数据量较大
像这种重前端的应用我们综合考虑了各种情况，最终决定采用前后端分离架构。
七、部署方案
前后端分离之后，应用在部署时也需要进行前后端分离。在进行前后端分离方案选择时，需要结合项目的实际情况和用户来考虑。
分离之前的架构
前后端分离之前，网盘的后端架构是Nginx服务和后端的PHP服务以及前端的静态资源都是部署在同一台服务器上。当浏览器发起访问请求时，如何请求的是静态资源，Nginx直接把静态资源返回给服务器；如果请求的是页面或后端服务，则经Nginx将请求转发到后端的PHP服务器，完成响应后经Nginx返回到浏览器。
此图中的Nginx属于后端机，主要针对前端机Nginx转发过来的请求进行识别弄转发给本机的PHP服务；前端机和后端机各有一个Nginx服务。
这个方案比较简单，易于实现，而且能到达前后端解耦的目的。而且很多公司目前都是基于这种架构或者一定的变形来实现的web应用。
但是对于页面量比较大，需要有良好SEO的应用来说，此方案缺点也较为明显。因为 Nginx只是向浏览器返回页面静态资源，而国内的搜索引擎爬虫只会抓取静态数据， 不会解析页面中的js，这使得应用得不到良好的搜索引擎支持。同时因为Nginx不会进行页面的组装渲染，需要把静态页面返回到浏览器，然后完成渲染工作，这加重了浏览器的渲染负担。
另外，由于这种架构使得前端工程师的工作范围只局限在了浏览器一侧，导致在进行一些特殊的性能优化时，前端工程师无法独立完成，还需要后端开发人员的配合，这也一定程度上影响了双方的进度。
分离之后的架构
前后端分离之后，我们在原先的架构只上再单独增加了一个Node Server作为中间层，将前端资源部署到Node Server中。Node Server还实现了一层数据代理服务，负责与提供数据的后端服务进行通信。
并且还在这个基础上增加并使用了前端机（前端机是对所有的请求进行预处理和负载均衡，然后再转发给后端机。）的Nginx服务，浏览器发起的请求经过前端机的Nginx进行分发，URL请求统一分发到Node Server，在Node Server中根据请求类型从后端服务器上通过RPC服务请求页面的模板数据，然后进行页面的组装和渲染；API请求则直接转发到后端服务器，完成响应。
注：此图中的Nginx属于前端机。
前后端分离方案对比
前后端分离并非仅仅只是前后端开发的分工，而是在开发期进行代码存放分离、前后 端开发职责分离，前后端能够独立进行开发测试;在运行期进行应用部署分离，前后 端之间通过HTTP请求进行通讯。前后端分离的开发模式与传统模式相比，能为我们 提升开发效率、增强代码可维护性，让我们有规划地打造一个前后端并重的精益开发 团队，更好地应对越来越复杂多变的Web应用开发需求。
这是一篇分享在前后端分离路上收获的点点滴滴的文章，以此来为准备尝试前后端分离或者想了解前后端分离的童鞋做一个大体的讲解。
尝试与改变
如果你没有尝试过前后端分离的工作流程，那么可以先试想一下这样的流程改变：
把流程从
- PM：“我要这个功能”
- 后端：“这个先找前端做个模板”
- 前端：“模板做完了”
- 后端：“我来对接一下，这里样式不对”
- 前端：“我改完了”
- 后端：“功能交付”
- PM：“春节要加这个活动”
- 后端：“这个先找前端改个模板”
- 前端：“模板做完了”
- 后端：“我来对接一下，这里样式不对”
- 前端：“我改完了” 后端：“功能交付”
- 变成 PM：“我要这个功能”
- 前端：“我要接口”
- 后端：“接口完成了”
- 前端：“我来对接一下，功能交付”
- PM：“春节要加这个活动”
- 前端：“需要增加接口”
- 后端：“接口完成了”
- 前端：“我来对接一下，功能交付”
由此可见，前后端分离的主要概念就是：后台只需提供API接口，前端调用AJAX实现数据呈现。
现状与分歧
作为一名前端开发人员，我们应该尝试一些新颖的技术，完善每一个细节性的问题，不断突破自我。虽然前后端分离已经算不上什么新颖的技术或思路，但是目前很多后台开发人员甚至前端开发人员都没有接触过。
据我个人的了解，如果在一个部门里，部门人员全是后台开发人员，前端的一些页面也是由后台人员完成的，那么前后端分离对于他们而言可能是一片未知的领域，项目大多是前后端强耦合的，甚至不存在前端的概念。
在不重视前端的公司或部门，不了解前后端分离这也无可厚非。在我刚进入一个全是后台开发人员的部门的时候，整个部门就我一个前端，我刚开始的主要职责就是负责项目前端页面的制作和JS功能的实现，虽然部门有前后端分离的意识，但都不知该如何去实践。
在那时，部门的后台人员认为前后端分离就是后台不再需要写HTML和JS了，可以交给前端来做了，然而这只能叫做前后端分工。
以上讲述的是一种情况: 不了解前后端分离，也不知如何去实践的。下面还有一种情况：了解前后端分离，但不想去尝试的。
针对第二种情况，很多人也做过相应的解释，其实这就涉及到“前后端分离的利弊”问题。很多后台人员会认为自己所做的那一套没有问题，即便后台套用前端html也是司空见惯，一直是大势所趋，后台MVC框架也是这么推荐使用的，很合理。
这时候前端开发人员在部门中的话语权往往是不够的，或者认为后台开发人员的意见永远是对的，没有主观性。
相反，也有可能是后台开发人员非常推荐前后端分离，而前端开发人员不想去实践的。这时候前端会认为后台开发人员在瞎折腾，之前前后端不分离项目做起来都很顺利，分离了反而会给自己带来额外的工作量和学习成本，而这就取决于前端的技术能力和见识了。
当然，这也是我个人认为的前后端分离所存在的一些现状和分歧所在。
场景与要求
对于前后端分离的应用场景，不是所有的场景都适合，但是大多数项目都能够通过前后端分离来实现。
由于我主要从事企业级后台应用的前端开发工作，个人认为对于后台应用的开发来说，前后端分离带来的利是远大于弊的。
大多数后台应用我们都可以做成SPA应用（单页应用），而单页应用最主要的特点就是局部刷新，这通过前端控制路由调用AJAX，后台提供接口便可以实现，而且这样的方式用户体验更加友好，网页加载更加快速，开发和维护成本也降低了不少，效率明显提升。
同样的，在展示类网站和移动APP页面中前后端分离也同样试用。前后端不分离的情况下，服务端要单独针对Web端做处理，返回完整HTML，这样势必增加服务端的复杂度，可维护性差，而web端需要加载完整的HTML，一定程度上影响网页性能，这对于移动端性能为王的地方非常的不友好。
随着前端技术的发展和迭代，前端MVC框架应运而生，利用目前主流的前端框架，如React、Vue、Angular等我们可以轻松的构建起一个无需服务器端渲染就可以展示的网站，同时这类框架都提供了前端路由功能，后台可以不再控制路由的跳转，将原本属于前端的业务逻辑全部丢给前端，这样前后端分离可以说是最为彻底。下面是一段前端控制路由的代码：
'use strict'
export default function (router) {
router.map({
'/': {
component: function (resolve) {
require(['./PC.vue'], resolve)
}
},
'/m/:params': {
component: function (resolve) {
require(['./Mobile.vue'], resolve)
}
},
'/p': {
component: function (resolve) {
require(['./PC.vue'], resolve)
},
subRoutes: {
'/process/:username': {
component: function (resolve) {
require(['./components/Process.vue'], resolve)
}
}
}
}
})
}
前后端分离的实现对技术人员尤其是前端人员的要求会上升一个层次，前端的工作不只是切页面写模板或是处理一些简单的js逻辑，前端需要处理服务器返回的各种数据格式，还需要掌握一系列的数据处理逻辑、MVC思想和各种主流框架。
优势与意义
对于前后端分离的意义我们也可以看做是前端渲染的意义，我主要总结了下面四点：
1.彻底解放前端
前端不再需要向后台提供模板或是后台在前端html中嵌入后台代码，如：
<!--服务器端渲染 -->
<select>
<option value=''>--请选择所属业务--</option>
{% for p in p_list %}
<option value="{{ p }}">{{ p }}</option>
{% endfor %}
</select>这是前后端耦合的，可读性差。
<!--前端渲染 -->
<template>
<select id="rander">
<option value=''>--请选择所属业务--</option>
<option v-for="list in lists" :value="list" v-text="list"></option>
</select>
</template>
<script>
export default {
data: {
return {
lists: ['选项一', '选项二', '选项三', '选项四']
}
}，
ready: function () {
this.$http({
url: '/demo/',
method: 'POST',
})
.then(function (response) {
this.lists = response.data.lists // 获取服务器端数据并渲染
})
}
}
</script>
上面是前端渲染的一段代码，前端通过AJAX调用后台接口，数据逻辑放在前端，由前端维护。
2.提高工作效率，分工更加明确
前后端分离的工作流程可以使前端只关注前端的事，后台只关心后台的活，两者开发可以同时进行，在后台还没有时间提供接口的时候，前端可以先将数据写死或者调用本地的json文件即可，页面的增加和路由的修改也不必再去麻烦后台，开发更加灵活。
3.局部性能提升
通过前端路由的配置，我们可以实现页面的按需加载，无需一开始加载首页便加载网站的所有的资源，服务器也不再需要解析前端页面，在页面交互及用户体验上有所提升。
4.降低维护成本
通过目前主流的前端MVC框架，我们可以非常快速的定位及发现问题的所在，客户端的问题不再需要后台人员参与及调试，代码重构及可维护性增强。
心得与体会
一路走来，项目一个接着一个，从一开始的后台控制路由、后台渲染页面到现在的前端控制路由、前端渲染数据，工作流程和方式都发生了很大的变化。每当遇到下面情形的时候，我都会为前后端分离带来的优势而感慨一番：
- 项目一开始制作前端页面的时候，我不再需要后台给我配置服务器环境了
- 项目的前端文件可以在需要调用后台接口的时候丢进服务器就好了，完全不需要事先放进去
- 增加一个项目页面需要配置路由的时候不再需要让后台同事给我加了，自己前端搞定
- 前端文件里不再掺杂后台的代码逻辑了，看起来舒服多了
- 页面跳转比之前更加流畅了，局部渲染局部加载非常快速
- 页面模板可以重复使用了，前端组件化开发提高了开发效率
等等。面对快速发展的前端，我们应该去适应其带来的工作方式和流程的改变，目前的前后端分离的工作方式必然是今后的趋势所在，作为一个前端开发人员，我们应当承担这个普及前端新知识和改变现状的职责。
只有尝试了才知道适不适合，只有切身体会才能辨别谁是谁非，本文并非推崇一定要前后端分离，而是希望大家在合适的应用场景下去尝试前后端分离，在丰富经验的同时或许也会擦出火花。
其他优质文章 ：
前端行业发展：
- Web 前端分为哪几个大方向，工资待遇如何，辛苦吗？
- 找前端工作会不会很难？
- 现在web前端的工资怎样？
- 前端开发就业情况如何？
前端工作内容：
- 前端工程师主要工作内容是什么？
- 前端开发是做什么的？工作职责有哪些？
前端学习路线：
- 怎么学习前端开发？求推荐学习路线？
前端必读书籍：
- 前端开发工程师必读书籍有哪些值得推荐？
面试相关：
- 关于前端Vue框架的面试题，面试官可能会问到哪些？
- 【一定要收藏】32000字的前端面试题总结！！！
- web前端简历个人技能该怎么写?
- 前端简历中项目描述怎么写能够更加的优雅？
- 面试前端工程师简历应该怎么写才容易通过？
- 自学 web 前端人怎么找工作？
- 自学前端简历怎么写啊？
HTML教程：
- HTML5入门教程（含新特性），从入门到精通
- HTML图文教程（表单域/文本框与密码框/单选按钮与复选框）
- HTML图文教程（选按钮与复选框/input标签/提交按钮与重置按钮）
- HTML图文教程（通按钮/文件域/label/下拉表单）
- HTML零基础入门教程， 零基础学习HTML网页制作（HTML基本结构）
- HTML零基础入门教程， 零基础学习HTML网页制作（HTML 标签）
Koa2教程：
- Koa2框架是什么？Koa框架教程快速入门Koa中间件
- Koa2框架路由应用，Koa2前景、Koa2中间件
- Koa2异常处理
VUE教程：
- 最全的vue学习教程来了，vue模块化组件超级好用，vue项目推荐，vue项目结构搭建，案例分析
其他：
- 13 个有趣且实用的 CSS 框架 / 组件
- 有哪些好的前端社区？
其实你总结的也差不多了
在我个人看来，首先什么是前后端分离？最核心的就是无论你后端换了什么语言，换了什么人去编写，换了什么样的服务器，只要你们定义的一个接口规则不变，然后不会影响到用户的使用，数据的一个展示。
同时反过来也一样，无论你前端换了什么UI框架，欸，我今天用easyui，明天我用layui，后天我用bootstrap，你也能够根据定义的接口文档去展示相关数据和效果，那么就是前后端分离。
说白了就是相互之间是独立的，这就是为什么有前后端分离这个观点出来，并且大家都认可不迟反对态度，恰恰就是说明前后端分离当中的两个字，“分离”
看站在什么角度去理解问题。
如果是以一个后端的角度理解前后分离，严格意义上，就是指在过去传统的服务器输出的HTML（具体你是PHP也好，JSP也好，Java模板也好，就以这网页右键查看源代码，服务器端输出的原始html代码为标准），不再由服务器负责输出，而是转由前端的组件来渲染网页的主界面。
这并没有强制要求静态资源和数据接口必须（或者不必须）要在同一个服务器上，完全可以在两个不同的服务器上。
只是，最终你所有初始化JS组件的那个入口的html文件，必须要尽量和数据接口在同一个服务器上，否则就会存在同源性CORS的检查限制要求（或者你的数据接口那里允许来自这个host的请求），即如果你连初始化的html都作为静态资源放到了CDN上，就必须在数据接口提供CORS请求的允许（很多同行一直问我这个问题）。
三大前端框架，并不是前后分离的唯一选择。App开发严格意义上就是前后分离的（WebView那些另说），所以如果你们自己的应用，本身也有明确分工，模板一套，数据又是另一套，其实也算是前后分离。
但你这第三个问题很含糊，因为前后分离，某种程度上，就要求了，前端可以不依赖于后端环境单独推送上静态资源服务器（可不是吗，UI逻辑都在你这里掌控着）。所以具体要看你实际项目，两边服务器的各自部署方式，要按照分离的概念，就是彼此之间的解耦降解，各自独立存在。但这顶多算是两个服务之间的分离，并没有到前后分离。
如果以你第三个问题，我会觉得，你应该将第一个服务，直接写成前端组件，然后从第二个服务那里获取数据。那就是前后分离，概念也比较清晰。
在说前后端分离之前，我们先要弄清楚这几个概念，大家可能经常听到前端，后端或者是大前端的一些概念，这些概念是怎么产生的呢？什么是前端，什么是后端，什么是前后端不分离？只有了解了这些，那么前后端分离你就懂了。
首先我讲一下什么是前端，在讲前端之前我先问大家一个问题，我们经常提到的JavaScript是前端吗？用JS写的程序是前端吗？还是说只有前端工程师写的程序才叫前端？我常提到HTML，CSS这是前端吗？或者是我们常用的一些APP，或者是一些小程序，这些是前端吗？那么大前端又是什么呢？这些问题抛出来以后，刚开始学习编程的同学估计都有想放弃学习编程的这种想法了。
没有关系，也没有你想的那么复杂。在通常的情况下，我们说的这个前端都是指浏览器这一端，而浏览器这一端通常是用JS来实现的，所以用JS写大部分的程序都是前端，包括APP，包括小程序和H5等。而当nodeJS出现以后，用nodeJS写的后台部分，也会被人归为前端，为了区分之前的前端，给他起了一个名字叫做大前端。但是呢我们想一下，用这种语言来区分前后端他真的合适吗？我其实是持有保留态度的。
对于前后端的定义，我认为他不应该是以语言来定义，而是应该以他的运行环境去定义，如果实在服务端器的话，应该被称为后端，因为什么呢？因为你既看不到也摸不着。而运行在客户端，就应该被称为前端，因为你能够看得到。
我们再看一下什么是前后端不分离，在移动互联出现之前，有一种流行的说法叫做B/S和C/S架构，C/S架构指的就是Client Server，意思就是说在桌面程序上有一个客户端，然后连接远程的这个服务器端，用socket或者是http来传输数据。而B/S架构是什么呢，就是指的是用通过浏览器进行访问，不需要装一个客户端，B/S架构曾经一度被认为是C/S的替代者，好处是什么呢？就是它不需要安装，简单方便。所以那个时候的写法就是后端是控制一切的，所以在早期的Web开发过程中，我们大家都听说过什么PHP程序员啊，Java程序员啊或者是asp程序员，大家要干的活就是“全栈”，也就是说前后端通吃。那么当时的技术是怎样的呢？看一下这张图：
通常开发一个web的这种应用程序，多是以asp，php或者jsp这样的语言来编写，项目通常是由多个这种文件构成的，每个文件当中同时包含了HTML，CSS,JS这样混编的，系统整体负责处理业务逻辑，控制业面跳转和向用户展示业面等。
而这个浏览器是什么呢？浏览器他是一个翻译官，他是翻译程序员写的代码给用户看的，翻译的过程其实有一个高大上的词，很多人把他称之为渲染。也就是说我们在平常看到的一些漂亮的这个网页就是浏览器渲染出来的。这个架构的好处是什么呢？就是简单便捷。但是这么做其实有一个明显的弊端，如果这个页面复杂一点的话，那这个单页的代码就比较恐怖了，少则上千，多则上万。
所以说在以前的开发过程中，前端设计师一般只扮演一个切图的工作，只是简单地将UI设计师设计出来的原型图把它编程静态的HTML业面，比如说业面的交互逻辑，比如说后台的数据交互，这些工作都是由后台开发人员来实现的，而且更有可能的是什么呢，是后端的开发人员直接兼顾前端的对口工作，一边实现API的接口一边要开发网页，两个相互切换着做。这导致了后台程序员开发的工作压力特别大，这样不仅开发效率比较缓慢，而且代码难以维护。而我们讲的前后端分离的话下面来看一下这张图片：
前后端分离除了解决分工不均的这个问题之外，主要是将更多的交互的这个逻辑分配给前端来处理，而后端可以专注于本职的工作，比如说API接口，或者是进行权限控制，或者是进行运算这些都交给后端。那么前端就可以独立完成与用户交互的这样一个过程，在前后端分离的这个应用模式当中，后端仅返回前端所需要的这样的一个过程，不需要渲染HTML业面和控制前端的这样一个效果。
至于说用户看到什么样的效果呢，从后端请求的数据展现都是后端通过异步接口，不如说通过AJA/JSON这种方式提供的，前端只管展现，但是呢你不要以为只是在敲代码的这个时候把前端和后端进行分开就是前后端分离了。它彻底是解放了前端，前端不需要在向后台提供模板，或者是后台无需再前端HTML中嵌入后台的代码，两者可以同时开工，不需要相互依赖，使得这样的开发效率大大的提高。
链接： 程序开发中：什么是前后端分离？你搞清楚了吗？
出处：csdn
作者：老鬼。。。
通俗解释前后端分离就是
一帮不能写后段的前端菜鸡
和
一帮搞不定你前端的后段菜鸡
聚在一起
居然搞出了一个看起来比12306还好的网站。
不满足以上要求的均不是前后端分离。
如：
后端同学：你装个apache、php就行了。
前端：哦。
半小时后
前端：这个php报错是啥。
后端：哦 你再装个memcache就行。
半小时后：memecache和memcached都是什么呀。内心我去你。。。
后端：你为什么要用vue，好大呀，什么鬼。你的对象怎么这么大，要mvc分层好吗！！！？？？看我怎么写。这个文件专门写关于这个区域的controller，选择这个元素，关联元素时间和回调函数名，里面的逻辑写在另一个文件，状态单独一个文件全局变量保存。
前端：qnmdb！
后端：vue的绑定真恶心 v-bind。还是smarty好，双括号搞定。
前端：。。。
前端：这个点击函数怎么还是sql语句呀？好神奇。
后端：。。。
前端：这个东西你写吧。
两小时后。
后端：表单复杂联动不好写呀，状态太多，判断太多，你看这什么报错呀。好像选择后页面还有点卡。。
前后端分离只是降低了前端、后段程序员的门槛。
前端写后段，可能会在死在并发，或者io上。
后段写前端可能会死在效率和维护上。
服务器只提供纯数据，和页面模板。不提供html。
浏览器先获取页面模板，然后获取数据，在组合成html，在显示出来。
说说我对前后端分离的理解，就是你做你的后端功能，给我提供数据接口；我做我的视图，需要数据的时候我就用接口调用数据插入到DOM中，不用麻烦你后端给我调用函数了。
拿WordPress（PHP）作为网站系统来说，分离与不分离两种模式。
第一种：前后端分离
WordPress提供了REST API（ REST API Handbook），使用这些api接口就可以获取到文章对象数据，包括了文章的标题、摘要、内容、作者各种属性，我不再需要以下这些WordPress提供的后端函数来获取数据了。
<?php the_title();//获取文章标题 ?>
<?php the_content();//获取文章内容 ?>我只需要通过api接口获取到的数据插入到DOM就好了。这种方式就可以不用将WordPress安装在网站根目录了，随便安装在子目录，只当作后端数据服务就好了，不需要按照WordPress提供的PHP函数才能输出文章，而前端完全可以使用三大框架或着应用在第三方平台上，比如小程序。
第二种：前后端不分离
HTML结构中嵌套着各种WordPress提供的php函数，用来输出数据。比如这样的：
<?php
/*
Template Name:默认页面模板
*/
get_header();?>
<div class="page-content page">
<?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?>
<article>
<h2><?php the_title(); ?></h2>
<div class="article-content"><?php the_content(); ?></div>
<div class="article-footer">
<div class="article-footer-date"><span class="dashicons dashicons-calendar-alt"></span><?php echo get_the_date(); ?></div>
</div>
</article>
<?php endwhile; else: ?>
<p><?php echo '抱歉没有内容'; ?></p>
<?php endif; ?>
</div>
<?php get_footer();?>在PHP文件中，HTML结构混合着PHP代码。需要遵循WordPress系统的规则，你的前端页面必须要作为一个主题放在主题目录中，哪个是首页模板、哪个是分类归档模板、哪个是搜索模板都要按规矩来，而且要知道WordPress提供的函数才能输出数据。如果是前后端完全分离的，你可以不需要知道这些函数是干嘛的。
我觉得前后端分离最大好处在于可以将网站的数据“同步”到第三方平台，比如小程序或打包成移动端的APP。假如我有一个网站，现在小程序这么火，我也想把网站“搬”到小程序上，又假如小程序提供了储存服务，那我网站数据岂不是要复制一份搬过去，发布新文章的时候岂不是又要到小程序再发一次，这样完全就是两个数据一样的网站嘛，这跟服务器商家没区别了。好在，它只提供了入口，数据还是从原来的网站获取，那我就提供api接口给小程序调用数据，这样就只要管好原来网站的数据就好了，不需要一式N份。
不请自来啦~
对于前后端分离，现在一般的认为是MVVM的模式，就是后端同学写接口，前端做SPA。
其实个人认为这种对前后端分离的定义有点狭隘。我觉得前后端分离式前后端同学在工作职责上的分离。实现接口简单封装复杂的形式。
比如说，用vue、react、angular等框架写前端。或者是不用任何前端SPA框架，就纯一个页面一个页面的写，能实现效果就行。
除了上面的两种算是前后端分离的方式之外，还有一种个人认为比较高级的方式。
就是后端同学照样写后端，但是前端同学则是利用node.js，吧前端做成MVC的模式。这里我解释一下（有经验的大神可以不用在意下面的）。就是后端同学照样写逻辑，写接口。但是前端也同样需要用node搭建一个前端服务，在node后端将java后端的数据请求过来再将数据渲染到页面上。
这样前端既可以自己做数据缓存，也可以自己维护路由和session。而后端同学则可以专注写代码逻辑。既保证了服务端的逻辑清晰干净，易于维护，又保证了前端优秀的SEO。个人认为这种是比较高级的前后端分离方式。但是其实这里也产生了一个痛点。就是这已经不是简单的前后端分离了，而是前端、后端、UI三方的分离。因为作为一个前端开发，我可不想增加自己的工作量！
嘻嘻~皮一下！
其实还是从耦合度上看吧，如果一个项目前端和后端的开发有各自进度且不影响，并且始终遵循约定的接口文件进行交互，这就是前后端分离了，具体到业务逻辑放哪，数据从哪里来，这并不能用来判断是否前后端分离，但是渲染放前端是比较明显的分离现象了。
其实小项目没必要前后端分离，浪费人力不说还占资源，明明一些简单逻辑数据后端直接渲染得了，非得排个期去前端搞，最烦心的是接口文档这种事，就没见过从一而终的，无论过程中改哪个api，对双方都不好。所以才会有全栈的出现，全栈不是后端渲染，他也用前后端分离开发，但是一人做前后端分离，有时效率真的比多人快。
个人愚见，不喜勿喷啊
1.到底什么是前后端分离？
一般是指前端只依赖数据接口来访问后端，前后端可以采用不同的技术栈，前后端可以给不同的开发人员开发。在某些情况下，前后端可以独立变化，前端改了后端不变，或者多套前端用同样的后端。
2.静态资源和数据接口被部署在两个不同的服务上就算前后端分离？
这个更多是指部署架构中的动静分离。前后端分离更多是开发模式，不代表他们不能部署到一起。
3.接第二个问题，如果A服务器只负责部署页面，视图用jsp，并且只放静态资源，jsp输出的html经过浏览器渲染之后又依靠js异步从另一个服务取得所有动态数据再填充到html渲染，那这算不算前后端分离？
jsp通常会夹杂一些后端逻辑，它是属于服务端视图技术，所以它通常不会单独部署。如果退化到没有后端逻辑，那么就可以直接用html来做了。后半段，通过js异步获取数据并渲染，实现方式和通常的前后端分离是一致的，但前后端分离主要是开发的组织结构发生变化了，所以也是有差异的。