緣起
哈嘍大家周四好，趁着大家在團建的時候花一個下午學點兒東西，也是督促大家學習喲，希望大家看到老張的文章，可以有一丟丟的學習動力。不過話說過來，該吃的團建還是要去的，不能學我呀 [ /(ㄒoㄒ)/~~ ]，昨天開始搭建公司的前后端分離項目，糾結是 Iview 還是 ElementUI ，百思不得其解，都說處女座糾結，我一個巨蟹為何如此，歡迎大佬們給出意見和建議~~~
開發 Vue 的時候，哪一種前端樣式框架更好？
鑒於群里小伙伴問得最多的問題，這里找到Top3的其中之一，就是跨域問題（下次說說EFCore），當然這個問題是老生常談的問題了，而且在之前的時候也已經說過了，不知道大家在使用的時候怎么樣——坑來自於文章《框架之十二 || 三種跨域方式比較》。當然，大家會問了，既然都說過了，為何還要說呢，特別是使用 CORS 來實現跨域，很輕松，短短的幾行代碼就搞定了，但是或多或少會遇到這樣的問題，1、把Http和 Https 搞混了，失敗；2、如果是前端端口號不固定，會經常要后端配置端口號，麻煩；3、最重要的一點就是把我們的接口地址暴漏出去了，不爽；如果你不信，可以看看我之前自己的一個線上版本 http://vue.blog.azlinli.com/#/，
雖然接口數據很正常被獲取，但是接口地址還是不想暴露出去，欸？！那咋辦，這就是說到了今天說的內容了，大家看我寫的標題應該也能明白，⅖ 種方法—— 前邊的三種方法已經說了，這里再重溫下：
0、不跨域 —— 前后端寫在一起，別笑，還真的有人已經把Vue 和 .net 整合到一起了，不說明
1、JsonP —— 在JQ中挺好，弊端也有，淺嘗輒止
2、添加請求頭 —— 需要后端來設計，不推薦
3、CORS —— 這個是我在跨域中遇到的神器，優缺點上邊也說了，還是很不錯的，推薦使用
4、webpack 本地代理 —— dev 環境的一大神器，只需在 webpack 中三行配置，即可代理到本地，只能在本地，大弊端，不過仍推薦使用
5、Nginx 反向代理 —— 完美解決 Build 后生產環境中的跨域問題，配合以后的負載均衡，強烈推薦
因為前三種跨域方法，已經在之前的文章中提到了《框架之十二 || 三種跨域方式比較》 ，這里就不多說了，今天主要說說 Webpack 的本地代理，和Nginx反向代理實現跨域，完全不用對后端進行操作；
最終我們的 博客項目一 的呈現的效果 http://vueblog.neters.club/：發現以及成功代理到本地了，並且是發布到服務器版本
一、基於webpack 的 proxy 代理——開發環境很方便
1、Vue-Cli 3.0 新增全局配置文件 vue.config.js
vue項目搭建的時候，會有一個全局config配置文件，在 vue-cli 2.0 腳手架中，很明顯的把它放到了 config 的一個文件夾中，是這樣的，我們在 index.js 中可以端口號的配置，打包之后路徑的配置，圖片的配置 等等
但是 vue-cli 3.0 腳手架中，去掉了 config 這個文件夾，那我們如何配置呢，我們可以在項目根目錄新建一個 vue.config.js 文件，像之前的很多繁瑣配置，都可以在這個文件里配置啦。官方說明，vue.config.js 是一個可選的配置文件，如果項目的 (和 package.json 同級的) 根目錄中存在這個文件，那么它會被 @vue/cli-service 自動加載。你也可以使用 package.json 中的 vue 字段，但是注意這種寫法需要你嚴格遵照 JSON 的格式來寫。
我們就在根目錄下新建該文件，然后添加內容：
module.exports = { // 基本路徑 baseUrl: "/", // 輸出文件目錄 outputDir: "dist", // eslint-loader 是否在保存的時候檢查 lintOnSave: true, // webpack配置 // see https://github.com/vuejs/vue-cli/blob/dev/docs/webpack.md chainWebpack: () => {}, configureWebpack: () => {}, // 生產環境是否生成 sourceMap 文件 productionSourceMap: true, // css相關配置 css: { // 是否使用css分離插件 ExtractTextPlugin extract: true, // 開啟 CSS source maps? sourceMap: false, // css預設器配置項 loaderOptions: {}, // 啟用 CSS modules for all css / pre-processor files. modules: false }, // use thread-loader for babel & TS in production build // enabled by default if the machine has more than 1 cores parallel: require("os").cpus().length > 1, // PWA 插件相關配置 // see https://github.com/vuejs/vue-cli/tree/dev/packages/%40vue/cli-plugin-pwa pwa: {}, // webpack-dev-server 相關配置 devServer: { open: true, //配置自動啟動瀏覽器 host: "127.0.0.1",//主機 port: 6688, // 端口號自定義 https: false,//是否開啟https安全協議 hotOnly: false, // https:{type:Boolean} proxy: null, // 設置代理 before: app => {} }, // 第三方插件配置 pluginOptions: { // ... } };
相應的注釋都有，主要是配置 devServer ，從名字上也能看出來，這個是 dev 開發環境的服務配置，常用來配置我們的端口號 port ，還有一個就是 proxy 的設置代理。
2、配置 proxy 本地代理
將上邊的 proxy: null 注釋掉，然后修改代理設置：
proxy: { // 配置多個代理 "/api": {//定義代理名稱 target: "http://123.206.33.109:8081",//我們的接口域名地址 ws: true, changeOrigin: true,//允許跨域 pathRewrite: { // 路徑重寫， "^/apb": "" // 替換target中的請求地址，（這里無效，但是可以自定義處理） } } },
這樣，我們就把接口地址代理到了本地，那代理到本地，如何調用呢，請往下看。
3、修改接口api地址，http.js文件
還記得我們在 src 文件夾下有一個 api/http.js 文件么，這個就是配置我們的 http 請求相關的，其他的都不變，我們只需要把域名去掉即可，或者寫上本項目的域名：
// 配置API接口地址 var root1 = "http://localhost:58427/api";//沒有代理的本地api地址 var root2 = "http://123.206.33.109:8081/api/";//沒有代理的服務器api地址 var root = "/api/";//配置 proxy 代理的api地址，也可以寫成http://localhost:6688/api
其實說白了，就是在項目啟動的時候，在node服務器中，是把所有的 /abi == http://localhost:6688/api 的都指向了 http://123.206.33.109:8081 域名，這樣就實現了跨域
其他任何都不需要變，接口的使用還是原來的使用方法，這樣，我們在本地開發的時候，就可以獲取到后端api數據了，不用再去 .net core 中設置跨域CORS了，是不是很方便。
4、本地瀏覽效果
記得我們修改 vue.config.js 后要重啟下服務，然后就可以看到項目成功獲取數據，並代理到本地：
可以看到，我們已經把遠程接口數據 123.206.33.109 成功的代理到了本地 localhost:6688 ，是不是很簡單！
5、build 打包發布 IIS
那我們本地開發好了，是不是一切都穩妥了呢，我們可以試一試，通過 build 打包，生成 dist 文件夾，然后將文件夾拷貝到服務器，並配置 IIS ，這個很簡單，就和配置普通靜態頁面是一樣的，
我們發現雖然頁面可以瀏覽（可以渲染，證明我們的 vue 已經生效），但是卻獲取不到數據，這證明我們上邊的 proxy 代理，只是適用本地dev開發環境中：
截圖
雖然這個本地代理的方法很簡單，特別適合我們獨立開發，在跨域這一塊，完全不用和后端做處理，但是如何解決發布狀態的呢，請繼續往下看。
二、基於Nginx 的反向代理——打包發布一鍵搞定
這篇文章僅僅是如何使用 Nginx 作為一個反向代理服務器，具體的深入原理以及負載均衡器等等，我會在以后的微服務系列中說到（不知不覺又給自己玩了一個坑😭）。
1、Nginx的代理工作原理
反向代理（Reverse Proxy）方式是指以代理服務器來接受 Internet上 的連接請求，然后將請求轉發給內部網絡上的服務器；並將從服務器上得到的結果返回給 Internet 上請求連接的客戶端，此時代理服務器對外就表現為一個服務器。
通常的代理服務器，只用於代理內部網絡對 Internet 外部網絡的連接請求，客戶機必須指定代理服務器，並將本來要直接發送到 Web 服務器上的 http 請求發送到代理服務器中。不支持外部網絡對內部網絡的連接請求，因為內部網絡對外部網絡是不可見的。當一個代理服務器能夠代理外部網絡上的主機， 訪問內部網絡時，這種代理服務的方式稱為反向代理服務。此時代理服務器對外就表現為一個Web服務器，外部網絡就可以簡單把它當作一個標准的 Web 服務器 而不需要特定的配置。不同之處在於，這個服務器沒有保存任何網頁的真實數據，所有的靜態網頁或者CGI程序，都保存在內部的Web服務器上。因此對反向代 理服務器的攻擊並不會使得網頁信息遭到破壞，這樣就增強了Web服務器的安全性。
總結來說呢，就是我們通過 nginx 反向代理服務器處理我們的請求，具體的數據處理還是交給 IIS，然后得到處理過的數據以后，我們再發送給 Internet 請求的客戶端，這樣就不會存在跨域的問題了。
2、Nginx 下載與使用
下載地址：http://nginx.org/en/download.html
我選擇下載穩定版 1.14 ，下載好后解壓，然后就看到根目錄下的 Nginx.exe ，直接雙擊即可開啟服務，然后就會在任務管理器查看到已經啟動的 Nginx 代理服務。
因為默認的是80端口，大家的端口應該都已經被占用，所以我們需要修改端口
打開 config 文件夾下的 nginx.conf 文件，然后修改端口號
server { listen 8077; server_name localhost;
這個很簡單，這個時候記得要重啟 Nginx 服務，你可以采用命令的形式，不過我有時候會發現無效，我一般使用的時候，在任務管理器中把所有的 nginx 進程全部結束，然后雙擊 nginx.exe 開啟。
這個時候我們直接訪問 localhost:8077 就發現已經啟動成功了，只不過是 nginx 的歡迎頁。
老張說：這個時候你一定好奇，為什么僅僅配置下，就能訪問該端口呢，不信的話，你可以在 cmd 中 通過 netstat -an 命令來查看 8077 端口是否被使用
發現已經被監聽使用，如果還不相信，你可以創建一個 IIS 項目，然后配置 8077 端口，發現會報錯，這也就是說明了，8077端口已經被占用，准確來說是被 Nginx 占用的，所以，Nginx 和 IIS一樣都是可以作為反向代理服務器來使用，從而可以通過監聽端口來代理我們的項目的：
3、將上文打包后的 dist 文件，配置 Nginx 代理
1、將我們上邊 build 后的 dist 文件，放到咱們下載的 nginx 下的 html文件夾
2、配置代理
還是我們的 config/nginx.conf 文件，打開並配置 本地代理 ，注意注釋是用 # 號，不是 //
server { listen 8077;#監聽端口，也就是我們的項目端口 server_name localhost;#服務器主機 location / { root html;#監聽文件夾，默認是nginx下的html文件夾，也可以自定義物理路徑 E:\\Nginx\\test index index.html index.htm;#默認首次啟動的文件 } #配置本地代理規則 location /api {#名字取一個 api rewrite ^.+apb/?(.*)$ /$1 break; #路徑重寫機制（無用，但是你也可以自己定義，對路由進行變化） include uwsgi_params; proxy_pass http://123.206.33.109:8081; #api接口的域名地址 }
4、本地以及服務器發布預覽
這個時候，你再訪問 localhost:8077 就能看到我們的項目內容了，訪問頁面也能看到我們的數據了，代理成功！
這個時候僅僅是本地，那服務器行不行呢，我們只需要將我們的 nginx 文件夾拷貝到服務器，並且雙擊 nginx.exe 啟動代理服務，然后就可以啦！
是不是很簡單，只需要把http.js 的baseurl 修改一下，完全不用修改我們任何的調用接口地址，也不用修改后端，就可以實現跨域。
相關代理，包括 nginx 文件夾，我已經放到 git 上，大家可以自己看一看。
5、刷新后出現 404
如果使用Ngxin 部署，可能會出現刷新的時候，404 的問題，有復雜的，也有簡單的辦法，復雜的以后補充，這里先說下簡單的：
就是直接在 dist 中，復制 index.html ，然后重命名一個新文件 404.html ，這兩個文件是一模一樣的：
三、結語
本篇文章是接着上一篇跨域文章的下篇，通過這 5 種方法，很好的實現了跨域問題，不僅僅是在 Vue 項目中，其他任何都可以這么使用，完美的解決了問題，與 CORS 相比，Nginx 更有前端主動權，各有利弊，我更傾向於 Nginx 代理，因為以后會涉及到負載均衡的使用，好啦，明天說說 EFCore 的使用吧（注：這是我的一個坑，本來想寫一篇文章，但是發現比較簡單，大家看看官網就知道，或者看我的第二個DDD系列中，用到了這個EFCore，如果想了解，可以直接看源代碼和相關文章，很簡單的都是https://github.com/anjoy8/ChristDDD）。
四、Github
https://github.com/anjoy8/Blog.Vue