問題背景：項目里面有用到背景圖片，開發模式下正常，打包之后發現報404錯誤。查看發現是背景圖片引用路徑出錯。
解決方法：
.map { width: 100%; height: 397px; background: url(../../../static/backImgs/about5.png) no-repeat; background-size: 100% 397px; }
build下由原來的相對路徑 "./" 改為絕對路徑 "/"
詳細緣由：
vue項目在打包之后背景圖片訪問出錯？
首先，出錯點在url-loader上面。
// url-loader配置 // build/webpck.base.conf.js
{ test: /\.(png|jpe?g|gif|svg)(\?.*)?$/, loader: 'url-loader', query: { limit: 10000, name: utils.assetsPath('img/[name].[hash:7].[ext]') }
這里解釋一下上面這段url-loader配置，test是正則匹配規則，匹配項目中所有的以正則規則結尾的格式的文件，直白點就是所有的圖片（png，jpg，jpeg，gif，svg），然后用url-loader進行處理。
處理也有個規則如下，當不大於10000B的文件進行base64轉碼，就是將圖片轉為base64的格式。如果超過10KB的圖片就單獨打包到utils.assetsPath(‘img/[name].[hash:7].[ext]’) 這個目錄下（從build/utils.js和config/index.js可以知道這個路徑就是assetsPublicPath/assetsSubDirectory/img目錄，並且圖片名是進行hash之后的值，根目錄下面沒有static目錄，所以會創建一個static目錄，至於為什么最后沒有看見這個目錄后續再說），當我們創建了一個這樣的目錄之后，所以的圖片訪問路徑就成了對應的assetsPublicPath/assetsSubDirectory/img/'圖片名'。
到這里就可以確定，如果小於10KB的圖片轉為base64，大於10KB的圖片已經將圖片路徑改為了assetsPublicPath/assetsSubDirectory/img/'圖片名'，如果您的設置為assetsPublicPath: './'，所得路徑為./static/img/'圖片'
// 目前我們的目錄結構
index.html static
|--img |--'picname'
|--css |--app.css |--js |--app.js
注意相對路徑標識’./’，我們知道img為html標簽，他的路徑是由index.html開始訪問的，他走./static/img/'圖片名'是能正確訪問到圖片的，所以img的路徑沒問題，然后app.css訪問./static/img/'圖片名'是訪問錯誤的，因為在css目錄下並沒有static目錄。這樣就造成了路徑訪問失敗的問題。
解決辦法：
1、檢查config文件中的assetsPublicPath是否設置為’/’，而不是’./’ 。
注意區分’/’為絕對路徑，絕對路徑從網站靜態服務器根目錄查詢/static/img/圖片，這樣的路徑就是正確的
如果設置為’./’，路徑就變成了相對路徑，相對路徑會根據相對的文件目錄來確定文件資源，會造成上面分析的問題
2、vue-cli創建的vue項目，會自帶一個static目錄，將出錯圖片放在該目錄下面即可（正確解決辦法）
查看vue-cli創建項目的webpack配置文件可以找到一個將static目錄拷貝到dist目錄中。根據對資源的規划不同，將需要打包的資源放在src/assets目錄中，不需要打包的資源放入static目錄中。
關於base64
優點：base64就是一串字符串碼來表示的圖片，在加載頁面或者js的時候就一並加載過來，減少圖片引用時單獨的一次http請求。了解web端性能優化的同學都知道，http請求每次建立都會占用一定的時間，對於小圖請求來說，可能http建立請求的時間比圖片下載本身還長。所以對小圖進行base64轉碼是優化http請求，保證頁面加速渲染的一種手段。
缺點：base64缺點就是之前提到的，他會增加圖片本身的大小，對小圖片來說，增加大小導致js的請求增長完全能彌補多一個http請求的建立的時長，這種取舍是划算的。可是對於大圖來說，這樣的取舍是不划算的。
舉個例子：（以下數據都是隨便模擬，看看思路就行）
假如每次建立http時長為0.1s，網絡傳輸為100KB/s，每次轉base64增加體積為百分之二十；
- 一張10KB的圖片通過http請求下載為0.2s，他轉為base64之后為12KB，在js下載中，增加了12KB的大小，所以增加0.12S 所以轉base64能優化0.08s的頁面加載速度；
- 一張100KB的圖片通過http請求的速度是1.1s。轉base64之后大小為120KB，他會增加js的大小120KB，所以增加加載時間1.2s。這樣一算下來，轉為base64之后，並不能優化頁面加載速度，反而拖慢了0.1s的加載速度，為不划算。
在開發過程中，處理加載速度之外我們還得考慮並行下載的問題。如果全在一個js中，這個js沒下載完成之前，圖片也是沒有下載的，也就是轉base64之后，可以認為js和圖片是串行下載的。而走http請求，圖片是可以和js並行下載的。所以實際上需要更小的圖片才能更划算。