其實這個網上已經有了很多人寫了，為什麼我還要再寫這一篇部落格？因為我親身把他們生產的坑給踩了個通透（攤手。

正文開始

本次的專案是基於vue-cli生成的專案，採用的vue-router的history模式。到這裡相信大部人還是類似了，接下來就是一個坑死人不償命的網上諸多部落格都在採用的巨坑。
在進行打包的時候，很多部落格裡都寫了，將/config/index.js下，build中的assetsPublicPath從/改為./。我很後悔，為什麼當初這樣照做的時候不去思考為什麼，為什麼要這樣做，憑什麼？如果這個有問題為什麼webpack生成的時候不改反而一直放在那裡？是誰傻？問題先放在這裡，我們先按照那些教程走。修改完後npm run build

，這樣在你的專案下就生成了一個dist資料夾，裡面就是生成的靜態內容。假設現在你的dist資料夾已經在你的雲伺服器中了。接下來開始nginx的配置。
個人採用的是sudo apt-get install nginx安裝的nginx，現在在命令列下，
cd /etc/nginx/conf.d/, 並在該目錄下 sudo touch vueSite.conf，接下來修改該檔案內容。

server {
  listen 3000;  # 假設你專案監聽的是3000埠
  root /path/to/dist;
  location / {
      try_files $uri $uri/ /index.html;
  }
}
 

然後
sudo nginx -t檢查正確性，無誤後sudo nginx -s reload。
接下來在你的瀏覽器下訪問cloudserverhost:3000，就可以訪問到你的專案主頁了。
目前來看似乎是一切順利呢，網上的教程真棒棒哦~
然後你可以試試，在cloudserverhost:3000/path/subpath下重新整理試試，你會發現，頁面沒有了，瀏覽器器裡會報錯，你會發現請求的js/css等都變成了html頁面的內容。這個問題就是出在了./下，我不知道第一個這樣寫出來的人他的專案是不是很幸運的只有一級路徑，又或者他從來不會嘗試去重新整理頁面，否則這個問題是無可避免的，為什麼呢？./是相對路徑，/

則是絕對路徑，當你在二級路徑下重新整理重新請求資源，你的請求路徑是什麼？把請求路徑寫出來我們就會發現問題出在哪裡了。很難過，我寫這篇部落格只用不到10分鐘，找到這個問題卻用了差不多10小時，查了各種方法，我真是萬萬沒想到。
因此，正式上線的專案，沒有必要修改/config/index.js下，build中的assetsPublicPath。配置好nginx，你的專案就可以開始起飛了