vue域名

1、vue-cli生成的項目，怎麼像nginx那樣配置 域名？就是不要以localhost:8080方

雖然不知道抄nginx怎麼配置，但襲是我配置jboss的時候，中文域名還是解析為英文的，你配置對應的英文域名就可以了。最近我也轉戰nginx，正好我也有中文域名，等我找到了，告訴你，如果你知道了，你也告訴我一下埃

2、vue如何將項目部署到伺服器上並且使外網能夠訪問到

你的伺服器是什麼系統啊 ，，，linux LINUX、WINDOWS、NETWARE、UNIX。。

在linux

首先伺服器安裝node git nginxvue-cli

安裝好nginx 用你的公網ip訪問就可以看到 下面的頁面

然後進入到下面的路徑

vi default 你會看到nginx的默認配置

默認監聽80埠 根路徑

把你寫好的vue項目 上傳到github ，通過git clone 克隆到

伺服器

路徑下面

然後npm/yarn add/install 安裝依賴 然後npm run build

vi 打開html 下面的 index.html 可以看到

nginx默認的html

進入sites-enabled 發現 它裡面的 default 來自 sites-available的default

所以需要在 sites-available 新建一個文件 你的項目名命名就可以

在你新建的文件

我在site-available新建的文件是note-admin 映射到 sites-enables

注意路徑一定要寫全

最後重新載入下 nginx -s reload

打開瀏覽器 公網ip:埠號或者 域名訪問

這就可以了

還有 用express 部署這個 簡單些

3、vue axios 如何驗證域名可訪問

沒有該域名下可調用的介面的話不行哦

4、vue 前端項目在瀏覽器預覽為什麼域名後自動加上/#/

你使用了vue-router，且mode默認是hash，它會自動添加#/

5、Vue.js為什麼不支持templateUrl模式

Angular的世界裡，templateURL 或者 ng-include 允許使用者在運行時動態的載入遠程模板文件，這個看起來很方便，作為一個自帶功能，但是讓我們來重新審視下這個功能。

首先，它允許我們能夠編寫一個分離的html文件作為模板，這樣子我們就能在編輯的時候看到正確的語法高亮，這也是很多開發者喜歡的原因（註：我覺得這是因為現在的人越來越懶，越來越依賴IDE的原因）。但是分離你的js和html代碼真的是個好主意么看在Vue.js的組件中，js和html天然緊耦合，事實上，這些代碼在一個文件更簡單易懂。在2個文件中來回切換上下文邏輯實際上讓開發者更不爽。在vue的概念里，組件才是vue.js的基本構建單位，並不是模板文件。每一個vue.js的模板都伴隨著他的好基友js，分離他們太過於殘忍了。

其次，因為templateURL是在運行時通過ajax的方式載入模板，不需要構建步驟為了你分離的文件。開發的時候，這很爽，但是上線部署的時候，你就麻煩了。在HTTP2.0沒有大面積支持前，HTTP的請求數仍然是頁面載入的最關鍵因素。想像一下，在你的網站中，每個組件都是用templateURL，那麼頁面出來前，你可能需要載入幾十個HTTP請求。可能你並不知道，大多數的瀏覽器是限制同一域名的並發請求數量的。當你超過這個限額的時候，你頁面的初始渲染時間就得等待每次請求的返回。當然，有工具可以幫助你提前注冊你所有的模板，但是這就多了一個構建步驟，事實上，這就是大型網站的必然趨勢。

那麼，在沒有templateURL的情況下，我們怎麼處理開發環境問題呢看
在js裡面拼接字元串是很爛的做法，使用 <script type="x/template">這種偽模板也不咋樣。那麼，現在是時候提升技能，使用像Webpack或者Browserify這種流行的模塊構建器了。如果以前沒有使用過，可能有點望而卻步，但是相信我，這會有一個質的飛躍。對於大型網站和系統來說，適當的模塊化很必要。更重要的是，你可以編寫Vue組件在一個文件中，再加上語法高亮，自定義的預處理器，熱載入，ES6，內置css，自動前置。可以讓開發者提高10倍效率。

最後，Vue還能懶載入你的組件，加上使用wabpack非常容易，盡管這是為了解決一個問---構建頁面文件過於龐大，初始化比較慢，所以你最好還是分割開來比較好。

拋棄template，擁抱組件世界吧！！

以上是原文的翻譯，並非完全直譯，有很多自己的語言，大概意思相同，原諒我的文采不行。

個人覺得，Vue的組件思想跟React相似，把很多東西放在了js（這里是.vue文件）中，這種做法是把很多緊耦合的東西集中在一起管理，把原來分割開的css,html，js合成在一起，這個很像很多年的做法，所以很同意玉伯說的，看起來前端是在原地打轉了一圈，開發模式回到了從前的樣子，但是已經螺旋上升了哦，一切都在升級。

通過最近的使用來看，這種component的方式很方便，天然幫你做了解耦的分離，當然你需要轉化自己的思維模式，不能在用jquery的操作DOM方式，同時和Angular也有很多區別，Vue並非一個框架，而是更像一個類庫，這樣很靈活，當然也會有人使用非常hack的方式來編寫代碼，可能會很蛋疼，這就需要自己注意了，對於團隊而言，可以很好的積累各種組件，同時功能切分，合作起來更加容易，就看團隊對Vue的理解程度了。

6、vue項目proxyTable中怎樣配置多個target

配置一條就是指向一個target啊，多個目標路徑，參照回下面代碼

  proxyTable: {
      '/api/a': {
        target: 'http://192.168.0.118:8080',
        changeOrigin: true,
        pathRewrite: {
          '^答/api/a': '/'
        }
      },
      '/api/b': {
        target: 'http://192.168.0.119:8080',
        changeOrigin: true,
        pathRewrite: {
          '^/api/b': '/'
        }
      }

7、域名是什麼，干什麼用

是由一串用點分隔的字元組成的互聯網上某一台計算機或計算機組的名稱，用於在數據傳輸時標識計算機的電子方位。域名可以說是一個IP地址的代稱，目的是為了便於記憶後者。

在計算機網路上，使用IP數字地址的簡單做法，可以追溯到ARPANET時代。當時，網路上的每台計算機都採用主機文件（即我們俗稱的Hosts）進行解析。Hosts文件內包含對應計算機的IP地址，每個需要解析的主機都擁有主機文件。

主機數量的快速增長使得主機文件被頻繁更新。於是，1983年，保羅·莫卡派喬斯發明了域名解析服務和域名系統，隨後它們被引入ARPANET。

(7)vue域名擴展資料：

IP地址是網際網路主機的作為路由定址用的數字體標識，不容易記憶，因而產生了域名這一種字元型標識，它比IP地址更容易記憶。這也是域名的一個重要功能——為數字化的互聯網資源提供易於記憶的名稱。

另外，域名具有唯一性，在資源更改IP地址時，只需要進行新IP地址與恆定域名的轉換，即可實現將資源移動到網路地址拓撲中的不同物理位置。

基於以上兩個特性，域名還用於創建個體的唯一標識。任何組織和個人在提供網際網路資源時，都可以選擇與其名稱對應的域名，讓其他人輕松訪問這些資源。

8、一台伺服器，多個域名，怎麼同時啟動多個vue項目？

可以將多個域名解析到這台伺服器ip
然後在伺服器端配置項目就可以了

9、vue-cli與後台給的介面有跨域.跨域怎麼配置

跨域問題來源於JavaScript的同源策略，即只有協議+主機名+埠號(如存在)相同，則允許相互訪問。也就是說JavaScript只能訪問和操作自己域下的資源，不能訪問和操作其他域下的資源。在以前，前端和後端混雜在一起，比如JavaScript直接調用同系統裡面的一個Httphandler，就不存在跨域的問題，但是隨著現代的這種多種客戶端的流行，比如一個應用通常會有Web端，App端，以及WebApp端，各種客戶端通常會使用同一套的後台處理邏輯，即API，前後端分離的開發策略流行起來，前端只關注展現，通常使用JavaScript，後端處理邏輯和數據通常使用WebService來提供json數據。一般的前端頁面和後端的WebServiceAPI通常部署在不同的伺服器或者域名上。這樣，通過ajax請求WebService的時候，就會出現同源策略的問題。需要說明的是，同源策略是JavaScript裡面的限制，其他的編程語言，比如在C#，Java或者iOS等其他語言中是可以調用外部的WebService，也就是說，如果開發Native應用，是不存在這個問題的，但是如果開發Web或者Html5如WebApp，通常使用JavaScriptajax對WebService發起請求然後解析返回的值，這樣就可能存在跨域的問題。一般的，很容易想到，將外部的資源搬到同一個域上就能解決同源策略的限制的。即在Web網站上同時開發一個Http服務端頁面，所有JavaScript的請求都發到這個頁面上來，這個頁面在內部使用其他語言去調用外部的WebService。即添加一個代理層。這種方式可以解決問題，但是不夠直接和高效。目前，比較常見的跨域解決方案包括JSONP(JSONwithpadding)和CORS(Cross-originresourcesharing)。一些解決方案需要客戶端和服務端配合如JSOP，一些則只需要服務端配合處理比如CORS。下面分別介紹這兩種跨域方案，以及服務端WebService如何支持這兩種跨域方案。JSONP以及WebService的支持同源策略下，某個伺服器是無法獲取到伺服器以外的數據，但是html裡面的img,iframe和script等標簽是個例外，這些標簽可以通過src屬性請求到其他伺服器上的數據。而JSONP就是通過script節點src調用跨域的請求。

10、vue-resource 怎麼解決跨域問題

跨域問題來源於JavaScript的同源策略，即只有 協議+主機名+埠號 (如存在)相同，則允許相互訪問。也就是說JavaScript只能訪問和操作自己域下的資源，不能訪問和操作其他域下的資源。
在以前，前端和後端混雜在一起， 比如JavaScript直接調用同系統裡面的一個Httphandler，就不存在跨域的問題，但是隨著現代的這種多種客戶端的流行，比如一個應用通常會有Web端，App端，以及WebApp端，各種客戶端通常會使用同一套的後台處理邏輯，即API， 前後端分離的開發策略流行起來，前端只關注展現，通常使用JavaScript，後端處理邏輯和數據通常使用WebService來提供json數據。一般的前端頁面和後端的WebService API通常部署在不同的伺服器或者域名上。這樣，通過ajax請求WebService的時候，就會出現同源策略的問題。
需要說明的是，同源策略是JavaScript裡面的限制，其他的編程語言，比如在C#，Java或者iOS等其他語言中是可以調用外部的WebService，也就是說，如果開發Native應用，是不存在這個問題的，但是如果開發Web或者Html5如WebApp，通常使用JavaScript ajax對WebService發起請求然後解析返回的值，這樣就可能存在跨域的問題。
一般的，很容易想到，將外部的資源搬到同一個域上就能解決同源策略的限制的。即在Web網站上同時開發一個Http服務端頁面，所有JavaScript的請求都發到這個頁面上來，這個頁面在內部使用其他語言去調用外部的WebService。即添加一個代理層。這種方式可以解決問題，但是不夠直接和高效。
目前，比較常見的跨域解決方案包括JSONP (JSON with padding)和CORS (Cross-origin resource sharing )。一些解決方案需要客戶端和服務端配合如JSOP，一些則只需要服務端配合處理比如CORS。下面分別介紹這兩種跨域方案，以及服務端WebService如何支持這兩種跨域方案。
JSONP以及WebService的支持
同源策略下，某個伺服器是無法獲取到伺服器以外的數據，但是html裡面的img,iframe和script等標簽是個例外，這些標簽可以通過src屬性請求到其他伺服器上的數據。而JSONP就是通過script節點src調用跨域的請求。