步入编程行业之初，记得公司的传统项目开发都是采用模块化，就是各自开发自己的模块，前后端代码一起撸，当时觉得这种方式还是挺好的，页面样式，业务逻辑分析，调试代码等等都是自己一个人写，这样子比起联调，或许更方便吧。最后就是一个war包放到Tomcat，再加上Nginx和Redis搞一搞集群，项目就是这样子上线。后来接触一些互联网或者大型的项目，发现这种开发方式根本不适用，时间效率不说，做出来的产品也是不理想。对自己而已更是万金油，前后端都懂，但是都不精通。毕竟精力有限，时间紧迫，公司也不会花时间给你研究，于是就出现了前后端人员，要求必须精通一个领域。自己本来擅长搞后端的，硬是被经理忽悠搞前端。希望自己未来的编程之路能好好走下去，好了，以上是我的废话。
    记得一个牛逼人物写了一篇文章(不记得出处了，对作者表示歉意)，专门讨论为什么要前后端分离开发，发现说得挺有道理的，也能学到很多知识点和吹一下牛逼（如有不对请谅解，再不行就找他，不关我事），特此记录一下，以下是正文。

    前后端分离已成为互联网项目开发的业界标准使用方式，通过nginx+tomcat的方式（也可以中间加一个nodejs）有效的进行解耦，并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS等等）打下坚实的基础。
     这个步骤是系统架构从猿进化成人的必经之路。核心思想是前端html页面通过ajax调用后端的restuful api接口并使用json数据进行交互。
名词解释：在互联网架构中，
web服务器：一般指像nginx，apache这类的服务器，他们一般只能解析静态资源。
应用服务器：一般指像tomcat，jetty，resin这类的服务器可以解析动态资源也可以解析静态资源，但解析静态资源的能力没有web服务器好。
一般都是只有web服务器才能被外网访问，应用服务器只能内网访问。
术业有专攻（开发人员分离）
以前的JavaWeb项目大多数都是java程序员又当爹又当妈，又搞前（ajax/jquery/js/html/css等等），又搞后端（java/mysql/oracle等等）。随着时代的发展，渐渐的许多大中小公司开始把前后端的界限分的越来越明确，前端工程师只管前端的事情，后端工程师只管后端的事情。正所谓术业有专攻，一个人如果什么都会，那么他毕竟什么都不精。大中型公司需要专业人才，小公司需要全才，但是对于个人职业发展来说，我建议是分开。
 对于后端java工程师：
把精力放在java基础，设计模式，jvm原理，spring+springmvc原理及源码，linux，mysql事务隔离与锁机制，mongodb，http/tcp，多线程，分布式架构（dubbo，dubbox，spring cloud），弹性计算架构，微服务架构（springboot+zookeeper+docker+jenkins），java性能优化，以及相关的项目管理等等。
后端追求的是：三高（高并发，高可用，高性能），安全，存储，业务等等。
 对于前端工程师：
 把精力放在html5，css3，jquery，angularjs，bootstrap，reactjs，vuejs，webpack，less/sass，gulp，nodejs，Google V8引擎，javascript多线程，模块化，面向切面编程，设计模式，浏览器兼容性，性能优化等等。
前端追求的是：页面表现，速度流畅，兼容性，用户体验等等。
术业有专攻，这样你的核心竞争力才会越来越高，正所谓你往生活中投入什么，生活就会反馈给你什么。并且两端的发展都越来越高深，你想什么都会，那你毕竟什么都不精。通过将team分成前后端team，让两边的工程师更加专注各自的领域，独立治理，然后构建出一个全栈式的精益求精的team。
几曾何时，我们的JavaWeb项目都是使用了若干后台框架，springmvc/struts +spring + spring jdbc/hibernate/mybatis 等等。大多数项目在java后端都是分了三层，控制层（controller/action），业务层（service/manage），持久层（dao）。控制层负责接收参数，调用相关业务层，封装数据，以及路由&渲染到jsp页面。然后jsp页面上使用各种标签（jstl/el/struts标签等）或者手写java表达式（<%=%>）将后台的数据展现出来，玩的是MVC那套思路。
 我们先看这种情况：需求定完了，代码写完了，测试测完了，然后呢？要发布了吧？
你需要用maven或者eclipse等工具把你的代码打成一个war包，然后把这个war包发布到你的生产环境下的web容器（tomcat/jboss/weblogic/websphere/jetty/resin）里，对吧？
发布完了之后，你要启动你的web容器，开始提供服务，这时候你通过配置域名，dns等等相关，你的网站就可以访问了（假设你是个网站）。
 那我们来看，你的前后端代码是不是全都在那个war包里？包括你的js，css，图片，各种第三方的库，对吧？好，下面在浏览器中输入你的网站域名（www.xxx.com），之后发生了什么？（这个问题也是很多公司的面试题）
浏览器在通过域名通过dns服务器找到你的服务器外网ip,将http请求发送到你的服务器，在tcp3次握手之后（http下面是tcp/ip），通过tcp协议开始传输数据，你的服务器得到请求后，开始提供服务，接收参数，之后返回你的应答给浏览器，浏览器再通过content-type来解析你返回的内容，呈现给用户。
 那么我们来看，我们先假设你的首页中有100张图片，此时，用户的看似一次http请求，其实并不是一次，用户在第一次访问的时候，浏览器中不会有缓存，你的100张图片，浏览器要连着请求100次http请求（有人会跟我说http长连短连的问题，不在这里讨论），你的服务器接收这些请求，都需要耗费内存去创建socket来玩tcp传输（消耗你服务器上的计算资源）。
重点来了，这样的话，你的服务器的压力会非常大，因为页面中的所有请求都是只请求到你这台服务器上，如果1个人还好，如果10000个人并发访问呢（先不聊服务器集群，这里就说是单实例服务器），那你的服务器能扛住多少个tcp连接？你的带宽有多大？你的服务器的内存有多大？你的硬盘是高性能的吗？你能抗住多少IO？你给web服务器分的内存有多大？会不会宕机？
这就是为什么，越是大中型的web应用，他们越是要解耦。理论上你可以把你的数据库+应用服务+消息队列+缓存+用户上传的文件+日志+等等都扔在一台服务器上，你也不用玩什么服务治理，也不用做什么性能监控，什么报警机制等等，就乱成一锅粥好了。但是这样就好像是你把鸡蛋都放在一个篮子里，隐患非常大。如果因为一个子应用的内存不稳定导致整个服务器内存溢出而hung住，那你的整个网站就挂掉了。如果出意外挂掉，而恰好这时你们的业务又处于井喷式发展高峰期，那么恭喜你，业务成功被技术卡住，很可能会流失大量用户，后果不堪设想。
注意：技术一定是要走在业务前面的，否则你将错过最佳的发展期哟，此外，你的应用全部都耦合在一起，相当于一个巨石，当服务端负载能力不足时，一般会使用负载均衡的方式，将服务器做成集群，这样其实你是在水平扩展一块块巨石，性能加速度会越来越低，要知道，本身负载就低的功能or模块是没有必要水平扩展的，在本文中的例子就是你的性能瓶颈不在前端，那干嘛要水平扩展前端呢？？？还有发版部署上线的时候，我明明只改了后端的代码，为什么要前端也跟着发布呢？？
正常的互联网架构，是都要拆开的，你的web服务器集群，你的应用服务器集群+文件服务器集群+数据库服务器集群+消息队列集群+缓存集群等等。
JSP的痛点
以前的javaWeb项目大多数使用jsp作为页面层展示数据给用户，因为流量不高，因此也没有那么苛刻的性能要求，但现在是大数据时代，对于互联网项目的性能要求是越来越高，
因此原始的前后端耦合在一起的架构模式已经逐渐不能满足我们，因此我们需要需找一种解耦的方式，来大幅度提升我们的负载能力。
1.动态资源和静态资源全部耦合在一起，服务器压力大，因为服务器会收到各种http请求，例如css的http请求，js的，图片的等等。一旦服务器出现状况，前后台一起玩完，用户体验极差。
 2.UI出好设计图后，前端工程师只负责将设计图切成html，需要由java工程师来将html套成jsp页面，出错率较高（因为页面中经常会出现大量的js代码），修改问题时需要双方协同开发，效率低下。
 3.jsp必须要在支持java的web服务器里运行（例如tomcat，jetty，resin等），无法使用nginx等（nginx据说单实例http并发高达5w，这个优势要用上），性能提不上来。
 4.第一次请求jsp，必须要在web服务器中编译成servlet，第一次运行会较慢。
 5.每次请求jsp都是访问servlet再用输出流输出的html页面，效率没有直接使用html高（是每次哟，亲~）。
 6.jsp内有较多标签和表达式，前端工程师在修改页面时会捉襟见肘，遇到很多痛点。
 7.如果jsp中的内容很多，页面响应会很慢，因为是同步加载。
 8.需要前端工程师使用java的ide（例如eclipse），以及需要配置各种后端的开发环境，你们有考虑过前端工程师的感受吗。基于上述的一些痛点，我们应该把整个项目的开发权重往前移，实现前后端真正的解耦！
开发模式
以前老的方式是：
1.产品经历/领导/客户提出需求
2.UI做出设计图
3.前端工程师做html页面
4.后端工程师将html页面套成jsp页面（前后端强依赖，后端必须要等前端的html做好才能套jsp。如果html发生变更，就更痛了，开发效率低）
5.集成出现问题
6.前端返工
7.后端返工
8.二次集成
9.集成成功
10.交付
 新的方式是：
1.产品经历/领导/客户提出需求
2.UI做出设计图
3.前后端约定接口&数据&参数
4.前后端并行开发（无强依赖，可前后端并行开发，如果需求变更，只要接口&参数不变，就不用两边都修改代码，开发效率高）
5.前后端集成
6.前端页面调整
7.集成成功
8.交付
请求方式 

以前老的方式是：
1.客户端请求
2.服务端的servlet或controller接收请求（后端控制路由与渲染页面，整个项目开发的权重大部分在后端）
3.调用service,dao代码完成业务逻辑
4.返回jsp
5.jsp展现一些动态的代码
新的方式是：
1.浏览器发送请求
2.直接到达html页面（前端控制路由与渲染页面，整个项目开发的权重前移）
3.html页面负责调用服务端接口产生数据（通过ajax等等，后台返回json格式数据，json数据格式因为简洁高效而取代xml）
4.填充html，展现动态效果，在页面上进行解析并操作DOM。
（有兴趣的童鞋可以访问一下阿里巴巴等大型网站，然后按一下F12，监控一下你刷新一次页面，他的http是怎么玩的，大多数都是单独请求后台数据，
使用json传输数据，而不是一个大而全的http请求把整个页面包括动+静全部返回过来）
 大量并发浏览器请求--->web服务器集群(nginx)--->应用服务器集群(tomcat)--->文件/数据库/缓存/消息队列服务器集群，同时又可以玩分模块，还可以按业务拆成一个个的小集群，为后面的架构升级做准备。
前后分离的优势
可以实现真正的前后端解耦，前端服务器使用nginx。前端/WEB服务器放的是css，js，图片等等一系列静态资源（甚至你还可以css，js，图片等资源放到特定的文件服务器，例如阿里云的oss，并使用cdn加速），前端服务器负责控制页面引用&跳转&路由，前端页面异步调用后端的接口，后端/应用服务器使用tomcat（把tomcat想象成一个数据提供者），加快整体响应速度。（这里需要使用一些前端工程化的框架比如nodejs，react，router，react，redux，webpack）
 2.发现bug，可以快速定位是谁的问题，不会出现互相踢皮球的现象。页面逻辑，跳转错误，浏览器兼容性问题，脚本错误，页面样式等问题，全部由前端工程师来负责。接口数据出错，数据没有提交成功，应答超时等问题，全部由后端工程师来解决。双方互不干扰，前端与后端是相亲相爱的一家人。
 3.在大并发情况下，我可以同时水平扩展前后端服务器，比如淘宝的一个首页就需要2000+台前端服务器做集群来抗住日均多少亿+的日均pv。（去参加阿里的技术峰会，听他们说他们的web容器都是自己写的，就算他单实例抗10万http并发，2000台是2亿http并发，并且他们还可以根据预知洪峰来无限拓展，很恐怖，就一个首页。。。）
 4.减少后端服务器的并发/负载压力除了接口以外的其他所有http请求全部转移到前端nginx上，接口的请求调用tomcat，参考nginx反向代理tomcat。且除了第一次页面请求外，浏览器会大量调用本地缓存。
 5.即使后端服务暂时超时或者宕机了，前端页面也会正常访问，只不过数据刷不出来而已。
 6.也许你也需要有微信相关的轻应用，那样你的接口完全可以共用，如果也有app相关的服务，那么只要通过一些代码重构，也可以大量复用接口，提升效率。（多端应用）
 7.页面显示的东西再多也不怕，因为是异步加载。
 8.nginx支持页面热部署，不用重启服务器，前端升级更无缝。
 9.增加代码的维护性&易读性（前后端耦在一起的代码读起来相当费劲）。
 10.提升开发效率，因为可以前后端并行开发，而不是像以前的强依赖。
 11.在nginx中部署证书，外网使用https访问，并且只开放443和80端口，其他端口一律关闭（防止黑客端口扫描），内网使用http，性能和安全都有保障。
 12.前端大量的组件代码得以复用，组件化，提升开发效率，抽出来！
注意事项
1.在开需求会议的时候，前后端工程师必须全部参加，并且需要制定好接口文档，后端工程师要写好测试用例（2个维度），不要让前端工程师充当你的专职测试，推荐使用chrome的插件postman或soapui或jmeter，service层的测试用例拿junit写。ps：前端也可以玩单元测试吗？
 2.上述的接口并不是java里的interface，说白了调用接口就是调用你controler里的方法。
 3.加重了前端团队的工作量，减轻了后端团队的工作量，提高了性能和可扩展性。
 4.我们需要一些前端的框架来解决类似于页面嵌套，分页，页面跳转控制等功能。（上面提到的那些前端框架）。
 5.如果你的项目很小，或者是一个单纯的内网项目，那你大可放心，不用任何架构而言，但是如果你的项目是外网项目，呵呵哒。
 6.以前还有人在使用类似于velocity/freemarker等模板框架来生成静态页面，仁者见仁智者见智。
 7.这篇文章主要的目的是说jsp在大型外网java web项目中被淘汰掉，可没说jsp可以完全不学，对于一些学生朋友来说，jsp/servlet等相关的java web基础还是要掌握牢的，不然你以为springmvc这种框架是基于什么来写的？
 8.如果页面上有一些权限等等相关的校验，那么这些相关的数据也可以通过ajax从接口里拿。
 9.对于既可以前端做也可以后端做的逻辑，我建议是放到前端，为什么？因为你的逻辑需要计算资源进行计算，如果放到后端去run逻辑，则会消耗带宽&内存&cpu等等计算资源，你要记住一点就是服务端的计算资源是有限的，而如果放到前端，使用的是客户端的计算资源，这样你的服务端负载就会下降（高并发场景）。类似于数据校验这种，前后端都需要做！
 10.前端需要有机制应对后端请求超时以及后端服务宕机的情况，友好的展示给用户。
 总结
前后端分离并非仅仅只是一种开发模式，而是一种架构模式（前后端分离架构）。
千万不要以为只有在撸代码的时候把前端和后端分开就是前后端分离了。需要区分前后端项目前端项目与后端项目是两个项目，放在两个不同的服务器，需要独立部署，两个不同的工程，两个不同的代码库，不同的开发人员。前后端工程师需要约定交互接口，实现并行开发，开发结束后需要进行独立部署，前端通过ajax来调用http请求调用后端的restful api。前端只需要关注页面的样式与动态数据的解析&渲染，而后端专注于具体业务逻辑。
 

一. 前后端分离开发具体实现
 
1 Visual Studio Code开发工具的安装
 
双击安装，即可成功
 
 
3.1.2 Visual Studio Code开发工具的配置
 
3.1.2.1、设置中文环境
 
设置中文环境
 
安装完毕后，vscode全部都是英文版本的，需要把vscode环境调整为中文版本。
 
 
调整步骤如下：
 
  
 
第一步：快捷键ctrl+shift+p
 
选择Configure Display Language
 
 
 
第二步：修改“locale”属性
 
 
 
第三步：设置完毕保存文件，重启vscode，就会显示中文。
 
 
 
 
	好了，到此vscode已经变成中文模式了，现在就可以进入到开发中了。
 
3.1.2.2 安装Vetur插件
 
 
功能表述
 
总：综合比较应该是目前 VSCode 上面最好用的 Vue 插件
 
分：
 
  
语法错误检查，包括 CSS/SCSS/LESS/Javascript/TypeScript
语法高亮，包括 html/jade/pug css/sass/scss/less/stylus js/ts
emmet 支持
代码自动补全（目前还是初级阶段），包括 HTML/CSS/SCSS/LESS/JavaScript/TypeScript
…
 
 
安装步骤，如下图操作
 
 
 
3.2 将商品开发的页面放到vs中
 
 
复制地址，直接在浏览器打开：
 
 
3.3.跨域问题
 
3.3.1.什么是跨域
 
跨域是指跨域名的访问，以下情况都属于跨域：
 
跨域原因说明
示例
域名不同
www.jd.com 与 www.taobao.com
域名相同，端口不同
www.jd.com:8080 与 www.jd.com:8081
二级域名不同
item.jd.com 与 miaosha.jd.com
协议不同
http://jd.com与https://jd.com
域名和ip地址

如果域名和端口都相同，但是请求路径不同，不属于跨域，如：
 
www.jd.com/item
 
www.jd.com/goods
 
而我们刚才是从file:///D:/VueWorkspace/102/goods00/Goods.html去访问http://localhost:8092/，这属于域名不同，跨域了。
 
3.3.2.为什么有跨域问题？
 
1 浏览器的同源策略引起跨域问题
 
2 跨域不一定会有跨域问题。
 
答：a.跨域没有引起问题：
因此：跨域问题 是针对ajax的一种限制。
 
但是这却给我们的开发带来了不便，而且在实际生成环境中，肯定会有很多台服务器之间交互，地址和端口都可能不同，怎么办？
 
3.3.3.解决跨域问题的方案
 
目前比较常用的跨域解决方案有3种：
 
 
Jsonp
 
最早的解决方案，利用script标签可以跨域的原理实现。
 
限制：
 
  
需要服务的支持
只能发起GET请求
 
 
nginx反向代理
 
思路是：利用nginx反向代理把跨域为不跨域，支持各种请求方式
 
 
CORS
 
规范化的跨域请求解决方案，安全可靠。
 
优势：
 
  
在服务端进行控制是否允许跨域，可自定义规则
支持各种请求方式：get、post、put、delete
限制访问的电脑的IP地址
 
缺点：
 
  
会产生额外的请求（可能发一次/二次请求）
 
 
我们这里会采用nginx搭建静态页面服务器+cors的跨域方案。
 
3.4.cors解决跨域
 
3.4.1.什么是cors
 
CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）。
 
它允许浏览器向跨源服务器，发出XMLHttpRequest请求，从而克服了AJAX只能同源使用的限制。
 
CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。
 
 
浏览器端：
 
目前，所有浏览器都支持该功能（IE10以下不行）。整个CORS通信过程，都是浏览器自动完成，不需要用户参与。
 
 
服务端：
 
CORS通信与AJAX没有任何差别，因此你不需要改变以前的业务逻辑。只不过，浏览器会在请求中携带一些头信息，我们需要以此判断是否运行其跨域，然后在响应头中加入一些信息即可。这一般通过过滤器完成即可。
 
 
3.4.2.CORS原理有点复杂(了解)
 
浏览器会将ajax请求分为两类，其处理方案略有差异：简单请求、特殊请求。
 
简单请求
 
只要同时满足以下两大条件，就属于简单请求。：
 
（1) 请求方法是以下三种方法之一：
 
HEAD
GET
POST
 
（2）HTTP的头信息不超出以下5种字段：
 
Accept
Accept-Language
Content-Language
Last-Event-ID
Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain
 
当浏览器发出的ajax请求是简单请求时，会在请求头中携带一个字段：Origin.
 
 
Origin中会指出当前请求属于哪个域（协议+域名+端口）。服务会根据这个值决定是否允许其跨域。
 
如果服务器允许跨域，需要在返回的响应头中携带下面信息：
 
Access-Control-Allow-Origin: http://localhost:8094
Access-Control-Allow-Credentials: true
Content-Type: text/html; charset=utf-8
 
Access-Control-Allow-Origin：可接受的域，是一个具体域名或者*，代表任意
Access-Control-Allow-Credentials：是否允许携带cookie，默认情况下，cors不会携带cookie，除非这个值是true
 
注意：
 
如果跨域请求要想操作cookie，需要满足3个条件：
 
服务的响应头中需要携带Access-Control-Allow-Credentials并且为true。
浏览器发起ajax需要指定withCredentials 为true
响应头中的Access-Control-Allow-Origin一定不能为*，必须是指定的域名
 
特殊请求
 
不符合简单请求的条件，会被浏览器判定为特殊请求,，例如请求方式为PUT。
 
 
 
预检请求
 
 
特殊请求会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）。
 
浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。
 
一个“预检”请求的样板：
 
OPTIONS /cors HTTP/1.1
Origin: http://localhost:8094
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: http://localhost:8094
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...
 
与简单请求相比，除了Origin以外，多了两个头：
 
Access-Control-Request-Method：接下来会用到的请求方式，比如PUT
Access-Control-Request-Headers：会额外用到的头信息
 
 
 
预检请求的响应
 
 
服务的收到预检请求，如果许可跨域，会发出响应：
 
HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://localhost:8094
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Access-Control-Max-Age: 1728000
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain
 
除了Access-Control-Allow-Origin和Access-Control-Allow-Credentials以外，这里又额外多出3个头：
 
Access-Control-Allow-Methods：允许访问的方式
Access-Control-Allow-Headers：允许携带的头
Access-Control-Max-Age：本次许可的有效时长，单位是秒，过期之前的ajax请求就无需再次进行预检了
 
如果浏览器得到上述响应，则认定为可以跨域，后续就跟简单请求的处理是一样的了。
 
3.4.3.实现非常简单
 
虽然原理比较复杂，但是前面说过：
 
浏览器端都有浏览器自动完成，我们无需操心
服务端可以通过拦截器统一实现，不必每次都去进行跨域判定的编写。
 
事实上，SpringMVC已经帮我们写好了CORS的跨域过滤器：CorsFilter ,内部已经实现了刚才所讲的判定逻辑，我们直接用就好了。
 
在config目录中编写一个配置类，并且注册CorsFilter：
 
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.cors.CorsConfiguration;
import org.springframework.web.cors.UrlBasedCorsConfigurationSource;
import org.springframework.web.filter.CorsFilter;

@Configuration
public class GlobalCorsConfig {
    @Bean
    public CorsFilter corsFilter() {
        //1.添加CORS配置信息
        CorsConfiguration config = new CorsConfiguration();
        //1) 允许的域,不要写*，否则cookie就无法使用了
        config.addAllowedOrigin("http://localhost:8094");
        //2) 是否发送Cookie信息
        config.setAllowCredentials(true);
        //3) 允许的请求方式
        config.addAllowedMethod("OPTIONS");
        config.addAllowedMethod("HEAD");
        config.addAllowedMethod("GET");
        config.addAllowedMethod("PUT");
        config.addAllowedMethod("POST");
        config.addAllowedMethod("DELETE");
        config.addAllowedMethod("PATCH");
        // 4）允许的头信息
        config.addAllowedHeader("*");

        //2.添加映射路径，我们拦截一切请求
        UrlBasedCorsConfigurationSource configSource = new UrlBasedCorsConfigurationSource();
        configSource.registerCorsConfiguration("/**", config);

        //3.返回新的CorsFilter.
        return new CorsFilter(configSource);
    }
}
 
结构：
 
 
4.5.4.重启测试：还是无法访问
 
##3.5 nginx搭建静态HTML服务器
 
 
 
只需要修改nginx的config配置文件即可，然后启动
 
# windows文件服务器配置
# 搭建前后端分离页面服务器
server {
listen       8094;
server_name localhost;

charset utf-8;


#浏览器打开路径：localhost:8094(listen端口）/location设置的路径/文件.后缀
location ~ /.*\.(html|htm)$ {
#文件/图片保存在电脑的地址
root   D:\\VueWorkspace\\102\\goods00;
}
}
 
 
测试，OK

django前后端分离开发（三）——前后端联调
 
1、前端打包
 在vue项目路径下
 
npm run build
 
2、修改django后端setting.py配置
 
#修改
'DIRS': [os.path.join(BASE_DIR, 'ui/dist')]
#其中ui是vue项目名称

#新增
STATICFILES_DIRS = [os.path.join(BASE_DIR, 'ui/dist/static')]
#其中ui是vue项目名称
 
3、修改django项目下主urls.py
 
from django.views.generic import TemplateView

urlpatterns = [
    path('admin/', admin.site.urls),
    path('', TemplateView.as_view(template_name='index.html')),
]
 
4、启动django后端，通过http://127.0.0.1:8000/#/能访问到vue项目界面代表前后端联调初步成功
 
后续规划：前端关联后端端口不打包进行开发

 
通过nginx实现前后端分离开发联调
 
前后端分离开发联调的session问题
如何使用nginx实现前后端分离开发调试

 
前后端分离开发联调的session问题
 
对于session 这个词，相信做web开发的程序猿们都不会陌生，浏览器要与服务器进行交互就必须建立一个session。用户登录系统后，我们常常会把一些初始化信息和用户信息放在session，给后续的网络请求提供必要的信息。比如说，我们现在要获取某个用户的订单信息，最简单的方式是将用户的用户名以参数的形式传到后台服务器，服务器根据用户名查询该用户的订单信息并返回的前端，这种做法将用户信息暴露的太显眼，很容易被别有用心的人利用，比起这种做法更安全的方式是将用户信息放在session里，前端只请求响应的接口，服务器根据当前session确定目前登录的用户，然后查询相关信息返回给前端。
 
对于以前后端分离的方式进行开发的web项目，以 vue + springboot 的开发模式为例。开发的时候，vue工程需要起动一个server用于vue的开发调试，springboot工程需要启动一个server用于跑我们的后台程序，前端请求由vue工程的server发起，由于两个server拥有不同的端口号，这势必导致请求是跨域的，如果只是单单在服务端开启跨域请求权限，也不能满足我们之前说的在session中获取相关信息的功能，因为开启跨域访问只是放开了访问的大门，但是多次请求并不在同一个session里。
 
为了方便前后端分离开发的联调，我们可以利用nginx的反向代理，实现session的统一，也不需要专门开启跨域访问用于开发调试了。
 
如何使用nginx实现前后端分离开发调试
 
对于让请求的session统一其实很简单，只要保证我们的请求都是在同一个域的同一个会话里进行就OK了，具体我们可以利用nginx的反向代理实现，其原理如下图：
 
 如图所示，还是以vue + springboot的前后端分离模式开发为例，server1为vue工程调试启动的服务器，server2为springboot启动的后台服务，server1的ajax请求均是以 nginx ip:port/api/* 开头，如127.0.0.1/api/* ,将nginx对80端口进行监听，将nginx的默认请求转发到server1，将url为 /api/* 的请求转发到server2，调试的的时候直接访问http://127.0.0.1/ 就可以打开vue的调试服务器进行调试了。
 
下面附上nginx配置文件关键代码:
 
 server {
        listen       80;
        server_name  localhost;
		
        location / {
			proxy_pass http://127.0.0.1:8080;
        }
		
		location /api/ {
			proxy_pass http://127.0.0.1:9080;
		}
    }