整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
內容來源于@什么值得買APP，觀點僅代表作者本人 ｜作者：yasden
文章很長，有56張圖片，建議收藏后慢慢看。
每次看見值友的硬盤爆料，很多朋友首先問：“是不是疊瓦盤？”很多朋友都很鄙視疊瓦盤。我自己的使用心得是這樣的：疊瓦盤當然沒有企業盤好啦，14TB或者18TB的企業盤好不好？當然好啦！我更喜歡買4TB或者6TB的盤，理由是這樣的：要是運氣不好硬盤壞了，最多也是壞一個4TB或者一個6TB而已啦，要是壞14TB那就是14TB呀。都是亞馬遜海淘的用戶，反正保修都麻煩，不如就4TB、6TB這么買吧。14TB=4TB+6TB+4TB，一個頂3個了。我要三個硬盤一起壞（4TB+6TB+4TB），才相當于壞一個14TB。我就是這么想的。當然我下載BT有專用的N1下載機（N1盒子24小時下載電費便宜啊），我不會拿NAS來下載BT，因此我NAS用疊瓦盤好些年了，沒有壞過，所以我的用法是這樣的。個人還是喜歡疊瓦盤，圖他便宜
純粹 個人喜好，勿噴。
我家的威聯通NAS有4個硬盤位，只有第1個硬盤位有一個2TB的紅盤，剩下的3個硬盤位都是空的。應該有不少朋友和我一樣，不是所有的硬盤位都插滿硬盤吧？新買的硬盤，插到空的盤位之后，怎么設置呢？可以（1）擴充存儲池，（2）新建一個存儲池。教程來了。
我還是禁不住黑色星期五的低價，亞馬遜買了一塊6TB的藍盤，而且是疊瓦盤（見下圖），我只是想試試疊瓦盤到底能用多久？多久會用壞
黑5我還買了一塊4TB的紅盤，美國亞馬遜海外購上面買的，就下圖這樣一個硬盤加減震塑料放紙盒子里給我寄來了，連西數的包裝都沒有，硬盤外面就一個一次性封口的塑料袋（見下圖）：
西數6TB或以下的紅盤和藍盤都是疊瓦盤，紅盤要8TB以上才不是疊瓦盤，下圖的所有硬盤都是疊瓦盤。
新硬盤插入威聯通NAS之后的設置步驟來了：
我原來有一塊2TB的西數紅盤，插在1盤位上，顯示是1.82TB（見下圖）。
現在我把6TB的西數藍盤，插在3盤位上，系統識別出來這個6TB的藍盤是5.46TB（見下圖）。我現在要把這個6TB的西數藍盤投入使用。為什么不插在2盤位上？因為我黑5還買了一個4TB的紅盤，我打算把4TB紅盤插到2盤位，所以這個6TB的藍盤就插在第3盤位了。
點擊上圖的綠色數字3，進入查看3盤位硬盤的運行狀況，從下圖可以看出，狀況很好，我剛買回來拆封，當然通電時間顯示是0天0小時（見下圖）。
在上圖的界面，點擊右上角的“管理”按鈕，進入下圖的界面
點擊右上角的“擴充存儲池”，在下拉菜單再點“擴充存儲池”，進入下圖的界面。
選擇“創建并加入一個新的RAID組”，點擊“下一步”，進入下圖的界面。
在磁盤3前面打鉤，點擊下一步。
接下來點擊“擴充”，按照提示完成后面的操作，可以看出，6TB的新硬盤合并到原來2TB舊硬盤的“存儲池1”上，“存儲池1”的空間也從2TB變成最終的7.26TB（見下圖），電腦計算容量的方式和硬盤廠家有點差異，所以8TB電腦識別成7.26TB。
在下圖界面點擊右上角的“創建”按鈕：
這時候，在下拉菜單上，選擇“新存儲池”。
這時候會彈出下面的窗口，什么都不選，就點擊“下一步”繼續。
這時候，會顯示你插入的新硬盤（我剛剛在第3盤位插入了一個6TB的硬盤），在磁盤3前面打鉤，RAID類型選單獨（其他類型無法選擇，除非你插入了2塊以上的新硬盤），點擊“下一步”。
這時候會彈出下圖的界面：
不知道“啟用保證快照空間”是什么意思的話，點擊上圖的“什么是保證快照空間？”，彈出下圖的界面進行查看。
我不知道你們怎么設置的，我是按照下圖這么設置的，警報臨界值我設置成90%（后來我改成95%），就是硬盤使用超過90%容量時才警告空間不足，啟用保證快照空間我設置成5%，之后點擊“下一步”。當然你也可以不啟用警報臨界值，不啟用保證快照空間，直接點擊“下一步”。
之后出現下圖的界面，點擊“創建”。
大家看上圖，保留空間有12.19%，也就是說有401GB要浪費掉。大家看看，保留空間是用來干什么的（見下圖）。
點擊“創建”按鈕，出現下圖的提示。提示你，你剛才插入的那個6TB硬盤里面的數據會被刪除掉（我是剛買的新硬盤，無任何數據的，如果你插入的硬盤有數據，務必先備份，不然格式化就沒了），點擊“確定”。
之后出現下圖的界面。
等幾分鐘后，出現下圖的界面。
在上圖的界面點擊“新卷”，進入下圖的界面。
在上圖的界面，點擊“下一步”。在下圖的界面，卷容量選擇“最大”：
往下拉，“警報臨界值”不打鉤，其他的也不打鉤，點擊“下一步”。
之后出現下圖的界面，點擊“完成”。
之后出現下圖的提示：
在上圖的界面，你可以點擊“關閉”按鈕，在下圖的“存儲池2，初始化中。。。”的地方查看硬盤初始化的進度。
初始化完成后，還要進行硬盤優化，看下圖：
“初始化”加上“優化”，大概花了20分鐘時間，初始化大概用了5分鐘，優化花了15分鐘左右。當出現下圖的界面，代表全部完成了。
第7步是后面增加的，本來這篇文章寫到第6步已經完成了，等我寫完第6步，發現我黑5買的西數4TB紅盤也到了，因此，我將4TB紅盤插到盤位2上，擴充存儲池的步驟也演示給大家看（這一步的最后有一個細節，需要大家留意）。
首先當然是把4TB紅盤插到NAS的第2盤位上啦，威聯通的這款NAS支持熱拔插，不需要關NAS電源，直接帶電插入即可。插入之后，發現第2盤位也變綠色了：
點擊左側的“存儲”-“存儲/快照”。
在上圖的界面，點擊“DataVol1（系統）”，再點擊界面右上角的“管理”，進入下圖的界面。先來看看這個NAS原來的“存儲池1”，原來我是在盤位1上插入了一個2TB的紅盤，系統顯示1.7TB的容量（電腦識別的容量和硬盤廠家標注的容量略有差別）：
點擊“存儲”-“存儲/快照”-“存儲池1”-“管理”，進入下圖的界面。
在上圖的界面，點擊“擴充存儲池”，之后會出現一個下拉菜單（見下圖），在下拉菜單上點擊“擴充存儲池”。
之后會出現下圖的界面，在這個界面只能選擇“創建并加入一個新的RAID組”，點擊“下一步”。
之后出現下圖的界面，在這個界面勾選“磁盤2”，也就是你剛剛插入的4TB紅盤，點擊“下一步”。
之后會出現下圖的界面，點擊“擴充”。
然后會彈出一個對話框，警告你插入的這個4TB硬盤里面的數據會被格式化，如果你的硬盤有數據，務必先備份。點擊“確定”繼續。
之后會彈出下圖的界面。
過30秒左右，出現下圖的界面，點擊“確定”。
之后，你會發現，存儲池1已經擴容變成5.44TB了（原來的2TB紅盤+新買的4TB紅盤），但是已配置1.85TB，還有3.59TB的空間處于未配置的狀況（見下圖紅色方框圈出的地方）。
點擊“DataVol1（系統）”，再點擊界面右上角的“管理”，進入下圖的界面。在下圖的界面，點擊“調整卷大小”：
之后出現下圖的界面。在這個界面點擊“最大”-“應用”。
它會提示，保留一些可用空間（見下圖的提示）。
那就保留一些空間好了，最大是5447.23GB，“新容量”我就填“5400.23”GB好了，之后點擊“應用”。
然后會彈出下圖的界面，點擊“關閉”。
你可以在下圖這個界面查看進度，就是在那個“正在擴充。。。68%”的地方查看擴充進度。
大概5分鐘之后，就擴充完成了，之后可以在下圖的界面查看擴充之后的情況。擴充之后，存儲池1有5.39TB的已配置空間了，剩下47GB的“未配置空間”，你可以按照我上面的方法來繼續配置。
買來一塊新硬盤，插到威聯通NAS空的硬盤位上，可以有兩個選擇：（1）在原來舊的存儲池上擴充容量，或（2）新建一個存儲池。
兩種方式各有優缺點。第一種方法會節省不少硬盤空間，因為第二種方法新建一個存儲池會浪費掉一些新硬盤的空間。第二種方法的優點是：如果是準備后續要換成大容量硬盤的話，比如我這個3盤位的6T的空間用完了，只需要單獨拷貝存儲池2的6TB數據出來，刪掉存儲池2，換上新的硬盤，重新建立存儲池2即可。如果是第1種方法：準備后續換成大容量硬盤的話，比如想把其中一塊6TB的換成18TB的，用第1種方式擴充存儲池的情況下是做不到的，因為存儲池1有系統盤，存儲池1的硬盤無法拆出來單獨換，你要將存儲池1的硬盤都備份好之后，才能拆卸下來進行更換。
擴充存儲池后，新硬盤的容量處于一個“未配置”的狀況，要“配置”一下，也就是要“調整卷大小”之后，才能使用。
全文完，謝謝觀看。
作者聲明本文無利益相關，歡迎值友理性交流，和諧討論～
接：https://juejin.im/book/5b936540f265da0a9624b04b
《高性能網站建設指南》的作者 Steve Souders 曾在一篇博客中提到：
我的大部分性能優化工作都集中在 JavaScript 和 CSS 上，從早期的 Move Scripts to the Bottom 和 Put Stylesheets at the Top 規則。為了強調這些規則的重要性，我甚至說過，“JS 和 CSS 是頁面上最重要的部分”。
幾個月后，我意識到這是錯誤的。圖片才是頁面上最重要的部分。
我關注 JS 和 CSS 的重點也是如何能夠更快地下載圖片。圖片是用戶可以直觀看到的。他們并不會關注 JS 和 CSS。確實，JS 和 CSS 會影響圖片內容的展示，尤其是會影響圖片的展示方式（比如圖片輪播，CSS 背景圖和媒體查詢）。但是我認為 JS 和 CSS 只是展示圖片的方式。在頁面加載的過程中，應當先讓圖片和文字先展示，而不是試圖保證 JS 和 CSS 更快下載完成。
這段話可謂字字珠璣。此外，雅虎軍規和 Google 官方的最佳實踐也都將圖片優化列為前端性能優化必不可少的環節——圖片優化的優先級可見一斑。
就圖片這塊來說，與其說我們是在做“優化”，不如說我們是在做“權衡”。因為我們要做的事情，就是去壓縮圖片的體積（或者一開始就選取體積較小的圖片格式）。但這個優化操作，是以犧牲一部分成像質量為代價的。因此我們的主要任務，是盡可能地去尋求一個質量與性能之間的平衡點。
2019 年，圖片依然很大
這里先給大家介紹 HTTP-Archive 這個網站，它會定期抓取 Web 上的站點，并記錄資源的加載情況、Web API 的使用情況等頁面的詳細信息，并會對這些數據進行處理和分析以確定趨勢。通過它我們可以實時地看到世界范圍內的 Web 資源的統計結果。
截止到 2018 年 8 月，過去一年總的 web 資源的平均請求體積是這樣的：
而具體到圖片這一類的資源，平均請求體積是這樣的：
當然，隨著我們工程師在性能方面所做的努力越來越有成效，平均來說，不管是資源總量還是圖片體積，都在往越來越輕量的方向演化。這是一種值得肯定的進步。
但同時我們不得不承認，如圖所示的這個圖片體積，依然是太大了。圖片在所有資源中所占的比重，也足夠“觸目驚心”了。為了改變這個現狀，我們必須把圖片優化提上日程。
時下應用較為廣泛的 Web 圖片格式有 JPEG/JPG、PNG、WebP、Base64、SVG 等，這些格式都是很有故事的，值得我們好好研究一把。此外，老生常談的雪碧圖（CSS Sprites）至今也仍在一線的前端應用中發光發熱，我們也會有所提及。
不談業務場景的選型都是耍流氓。下面我們就結合具體的業務場景，一起來解開圖片選型的神秘面紗！
在計算機中，像素用二進制數來表示。不同的圖片格式中像素與二進制位數之間的對應關系是不同的。一個像素對應的二進制位數越多，它可以表示的顏色種類就越多，成像效果也就越細膩，文件體積相應也會越大。
一個二進制位表示兩種顏色（0|1 對應黑|白），如果一種圖片格式對應的二進制位數有 n 個，那么它就可以呈現 2^n 種顏色。
關鍵字：有損壓縮、體積小、加載快、不支持透明
JPG 的優點
JPG 最大的特點是有損壓縮。這種高效的壓縮算法使它成為了一種非常輕巧的圖片格式。另一方面，即使被稱為“有損”壓縮，JPG的壓縮方式仍然是一種高質量的壓縮方式：當我們把圖片體積壓縮至原有體積的 50% 以下時，JPG 仍然可以保持住 60% 的品質。此外，JPG 格式以 24 位存儲單個圖，可以呈現多達 1600 萬種顏色，足以應對大多數場景下對色彩的要求，這一點決定了它壓縮前后的質量損耗并不容易被我們人類的肉眼所察覺——前提是你用對了業務場景。
使用場景
JPG 適用于呈現色彩豐富的圖片，在我們日常開發中，JPG 圖片經常作為大的背景圖、輪播圖或 Banner 圖出現。
兩大電商網站對大圖的處理，是 JPG 圖片應用場景的最佳寫照：
打開淘寶首頁，我們可以發現頁面中最醒目、最龐大的圖片，一定是以 .jpg 為后綴的：
京東首頁也不例外：
使用 JPG 呈現大圖，既可以保住圖片的質量，又不會帶來令人頭疼的圖片體積，是當下比較推崇的一種方案。
JPG 的缺陷
有損壓縮在上文所展示的輪播圖上確實很難露出馬腳，但當它處理矢量圖形和 Logo 等線條感較強、顏色對比強烈的圖像時，人為壓縮導致的圖片模糊會相當明顯。
此外，JPEG 圖像不支持透明度處理，透明圖片需要召喚 PNG 來呈現。
關鍵字：無損壓縮、質量高、體積大、支持透明
PNG 的優點
PNG（可移植網絡圖形格式）是一種無損壓縮的高保真的圖片格式。8 和 24，這里都是二進制數的位數。按照我們前置知識里提到的對應關系，8 位的 PNG 最多支持 256 種顏色，而 24 位的可以呈現約 1600 萬種顏色。
PNG 圖片具有比 JPG 更強的色彩表現力，對線條的處理更加細膩，對透明度有良好的支持。它彌補了上文我們提到的 JPG 的局限性，唯一的 BUG 就是體積太大。
PNG-8 與 PNG-24 的選擇題
什么時候用 PNG-8，什么時候用 PNG-24，這是一個問題。
理論上來說，當你追求最佳的顯示效果、并且不在意文件體積大小時，是推薦使用 PNG-24 的。
但實踐當中，為了規避體積的問題，我們一般不用PNG去處理較復雜的圖像。當我們遇到適合 PNG 的場景時，也會優先選擇更為小巧的 PNG-8。
如何確定一張圖片是該用 PNG-8 還是 PNG-24 去呈現呢？好的做法是把圖片先按照這兩種格式分別輸出，看 PNG-8 輸出的結果是否會帶來肉眼可見的質量損耗，并且確認這種損耗是否在我們（尤其是你的 UI 設計師）可接受的范圍內，基于對比的結果去做判斷。
應用場景
前面我們提到，復雜的、色彩層次豐富的圖片，用 PNG 來處理的話，成本會比較高，我們一般會交給 JPG 去存儲。
考慮到 PNG 在處理線條和顏色對比度方面的優勢，我們主要用它來呈現小的 Logo、顏色簡單且對比強烈的圖片或背景等。
此時我們再次把目光轉向性能方面堪稱業界楷模的淘寶首頁，我們會發現它頁面上的 Logo，無論大小，還真的都是 PNG 格式：
主 Logo：
較小的 Logo：
顏色簡單、對比度較強的透明小圖也在 PNG 格式下有著良好的表現：
關鍵字：文本文件、體積小、不失真、兼容性好
SVG（可縮放矢量圖形）是一種基于 XML 語法的圖像格式。它和本文提及的其它圖片種類有著本質的不同：SVG 對圖像的處理不是基于像素點，而是是基于對圖像的形狀描述。
SVG 的特性
和性能關系最密切的一點就是：SVG 與 PNG 和 JPG 相比，文件體積更小，可壓縮性更強。
當然，作為矢量圖，它最顯著的優勢還是在于圖片可無限放大而不失真這一點上。這使得 SVG 即使是被放到視網膜屏幕上，也可以一如既往地展現出較好的成像品質——1 張 SVG 足以適配 n 種分辨率。
此外，SVG 是文本文件。我們既可以像寫代碼一樣定義 SVG，把它寫在 HTML 里、成為 DOM 的一部分，也可以把對圖形的描述寫入以 .svg 為后綴的獨立文件（SVG 文件在使用上與普通圖片文件無異）。這使得 SVG 文件可以被非常多的工具讀取和修改，具有較強的靈活性。
SVG 的局限性主要有兩個方面，一方面是它的渲染成本比較高，這點對性能來說是很不利的。另一方面，SVG 存在著其它圖片格式所沒有的學習成本（它是可編程的）。
SVG 的使用方式與應用場景
SVG 是文本文件，我們既可以像寫代碼一樣定義 SVG，把它寫在 HTML 里、成為 DOM 的一部分，也可以把對圖形的描述寫入以 .svg 為后綴的獨立文件（SVG 文件在使用上與普通圖片文件無異）。
將 SVG 寫入 HTML：
將 SVG 寫入獨立文件后引入 HTML:
<img src="文件名.svg" alt="">
在實際開發中，我們更多用到的是后者。很多情況下設計師會給到我們 SVG 文件，就算沒有設計師，我們還有非常好用的 在線矢量圖形庫。對于矢量圖，我們無須深究過多，只需要對其核心特性有所掌握、日后在應用時做到有跡可循即可。
關鍵字：文本文件、依賴編碼、小圖標解決方案
Base64 并非一種圖片格式，而是一種編碼方式。Base64 和雪碧圖一樣，是作為小圖標解決方案而存在的。在了解 Base64 之前，我們先來了解一下雪碧圖。
前置知識：最經典的小圖標解決方案——雪碧圖（CSS Sprites）
雪碧圖、CSS 精靈、CSS Sprites、圖像精靈，說的都是這個東西——一種將小圖標和背景圖像合并到一張圖片上，然后利用 CSS 的背景定位來顯示其中的每一部分的技術。
MDN 對雪碧圖的解釋已經非常到位：
圖像精靈（sprite，意為精靈），被運用于眾多使用大量小圖標的網頁應用之上。它可取圖像的一部分來使用，使得使用一個圖像文件替代多個小文件成為可能。相較于一個小圖標一個圖像文件，單獨一張圖片所需的 HTTP 請求更少，對內存和帶寬更加友好。
我們幾乎可以在每一個有小圖標出現的網站里找到雪碧圖的影子（下圖截取自京東首頁）：
和雪碧圖一樣，Base64 圖片的出現，也是為了減少加載網頁圖片時對服務器的請求次數，從而提升網頁性能。Base64 是作為雪碧圖的補充而存在的。
理解 Base64
通過我們上文的演示，大家不難看出，每次加載圖片，都是需要單獨向服務器請求這個圖片對應的資源的——這也就意味著一次 HTTP 請求的開銷。
Base64 是一種用于傳輸 8Bit 字節碼的編碼方式，通過對圖片進行 Base64 編碼，我們可以直接將編碼結果寫入 HTML 或者寫入 CSS，從而減少 HTTP 請求的次數。
我們來一起看一個實例，現在我有這么一個小小的放大鏡 Logo：
它對應的鏈接如下：
https://user-gold-cdn.xitu.io/2018/9/15/165db7e94699824b?w=22&h=22&f=png&s=3680
按照一貫的思路，我們加載圖片需要把圖片鏈接寫入 img 標簽：
<img src="https://user-gold-cdn.xitu.io/2018/9/15/165db7e94699824b?w=22&h=22&f=png&s=3680">
瀏覽器就會針對我們的圖片鏈接去發起一個資源請求。
但是如果我們對這個圖片進行 Base64 編碼，我們會得到一個很長很長的字符串，我們可以直接用這個字符串替換掉上文中的鏈接地址。你會發現瀏覽器原來是可以理解這個字符串的，它自動就將這個字符串解碼為了一個圖片，而不需再去發送 HTTP 請求。
Base64 的應用場景
上面這個實例，其實源自我們 掘金 網站 Header 部分的搜索欄 Logo：
既然 Base64 這么棒，我們何不把大圖也換成 Base64 呢？
這是因為，Base64 編碼后，圖片大小會膨脹為原文件的 4/3（這是由 Base64 的編碼原理決定的）。如果我們把大圖也編碼到 HTML 或 CSS 文件中，后者的體積會明顯增加，即便我們減少了 HTTP 請求，也無法彌補這龐大的體積帶來的性能開銷，得不償失。
在傳輸非常小的圖片的時候，Base64 帶來的文件體積膨脹、以及瀏覽器解析 Base64 的時間開銷，與它節省掉的 HTTP 請求開銷相比，可以忽略不計，這時候才能真正體現出它在性能方面的優勢。
因此，Base64 并非萬全之策，我們往往在一張圖片滿足以下條件時會對它應用 Base64 編碼：
Base64 編碼工具推薦
這里最推薦的是利用 webpack 來進行 Base64 的編碼——webpack 的 url-loader 非常聰明，它除了具備基本的 Base64 轉碼能力，還可以結合文件大小，幫我們判斷圖片是否有必要進行 Base64 編碼。
除此之外，市面上免費的 Base64 編解碼工具種類是非常多樣化的，有很多網站都提供在線編解碼的服務，大家選取自己認為順手的工具就好。
關鍵字：年輕的全能型選手
WebP 是今天在座各類圖片格式中最年輕的一位，它于 2010 年被提出， 是 Google 專為 Web 開發的一種旨在加快圖片加載速度的圖片格式，它支持有損壓縮和無損壓縮。
WebP 的優點
WebP 像 JPEG 一樣對細節豐富的圖片信手拈來，像 PNG 一樣支持透明，像 GIF 一樣可以顯示動態圖片——它集多種圖片文件格式的優點于一身。
WebP 的官方介紹對這一點有著更權威的闡述：
與 PNG 相比，WebP 無損圖像的尺寸縮小了 26％。在等效的 SSIM 質量指數下，WebP 有損圖像比同類 JPEG 圖像小 25-34％。 無損 WebP 支持透明度（也稱為 alpha 通道），僅需 22％ 的額外字節。對于有損 RGB 壓縮可接受的情況，有損 WebP 也支持透明度，與 PNG 相比，通常提供 3 倍的文件大小。
我們開篇提到，圖片優化是質量與性能的博弈，從這個角度看，WebP 無疑是真正的贏家。
WebP 的局限性
WebP 縱有千般好，但它畢竟太年輕。我們知道，任何新生事物，都逃不開兼容性的大坑。現在是 2018 年 9 月，WebP 的支持情況是這樣的：
坦白地說，雖然沒有特別慘（畢竟還有親爹 Chrome 在撐腰），但也足夠讓人望而卻步了。
此外，WebP 還會增加服務器的負擔——和編碼 JPG 文件相比，編碼同樣質量的 WebP 文件會占用更多的計算資源。
WebP 的應用場景
現在限制我們使用 WebP 的最大問題不是“這個圖片是否適合用 WebP 呈現”的問題，而是“瀏覽器是否允許 WebP”的問題，即我們上文談到的兼容性問題。具體來說，一旦我們選擇了 WebP，就要考慮在 Safari 等瀏覽器下它無法顯示的問題，也就是說我們需要準備 PlanB，準備降級方案。
目前真正把 WebP 格式落地到網頁中的網站并不是很多，這其中淘寶首頁對 WebP 兼容性問題的處理方式就非常有趣。我們可以打開 Chrome 的開發者工具搜索其源碼里的 WebP 關鍵字：
我們會發現檢索結果還是挺多的（單就圖示的加載結果來看，足足有?200?多條），下面大家注意一下這些 WebP 圖片的鏈接地址（以其中一個為例）：
<img src="http://img.alicdn.com/tps/i4/TB1CKSgIpXXXXccXXXX07tlTXXX-200-200.png_60x60.jpg_.webp" alt="手機app - 聚劃算" class="app-icon">
.webp 前面，還跟了一個 .jpg 后綴！
我們現在先大膽地猜測，這個圖片應該至少存在 jpg 和 webp 兩種格式，程序會根據瀏覽器的型號、以及該型號是否支持 WebP 這些信息來決定當前瀏覽器顯示的是 .webp 后綴還是 .jpg 后綴。帶著這個預判，我們打開并不支持 WebP 格式的 Safari 來進入同樣的頁面，再次搜索 WebP 關鍵字：
Safari 提示我們找不到，這也是情理之中。我們定位到剛剛示例的 WebP 圖片所在的元素，查看一下它在 Safari 里的圖片鏈接：
<img src="http://img.alicdn.com/tps/i4/TB1CKSgIpXXXXccXXXX07tlTXXX-200-200.png_60x60.jpg" alt="手機app - 聚劃算" class="app-icon">
我們看到同樣的一張圖片，在 Safari 中的后綴從 .webp 變成了 .jpg！看來果然如此——站點確實是先進行了兼容性的預判，在瀏覽器環境支持 WebP 的情況下，優先使用 WebP 格式，否則就把圖片降級為 JPG 格式（本質是對圖片的鏈接地址作簡單的字符串切割）。
此外，還有另一個維護性更強、更加靈活的方案——把判斷工作交給后端，由服務器根據 HTTP 請求頭部的 Accept 字段來決定返回什么格式的圖片。當 Accept 字段包含 image/webp 時，就返回 WebP 格式的圖片，否則返回原圖。這種做法的好處是，當瀏覽器對 WebP 格式圖片的兼容支持發生改變時，我們也不用再去更新自己的兼容判定代碼，只需要服務端像往常一樣對 Accept 字段進行檢查即可。
由此也可以看出，我們 WebP 格式的局限性確實比較明顯，如果決定使用 WebP，兼容性處理是必不可少的。
者復盤最近的電商拆單工作經歷，從原因、流程等方面進行分析，也讓大家不再踩坑。
像TB、PD一樣的平臺有多種店家，因發貨地不同則需要拆單。
根據商家拆單比較容易理解，比如你在電商平臺上買了二個商品，一個是玩具，一個是圖書。圖書和衣服基本都是平臺的東西，所以你買的這兩個東西很可能是兩個不同商家的。
當你購物車里面同時買了圖書和衣服的時候，盡管是你一次付款的，但由于背后是兩個不同的商家，所以會把你的這筆訂單拆成2個不同的子訂單，每個子訂單由相應的商家發貨。因為不同商家的貨都是存在自己商家的倉庫里面，所以不可能同時從2個不同的商家發貨，這也就是為什么購物車里面要根據不同的商家進行拆單。
自營平臺本身有多家倉庫，用戶購買后會從不同的倉庫發貨。這種情況就是，自營平臺內的商品會有品類的限制，每一個品類都會有特殊的屬性，比如有效期、超大物品、易碎品之類的需要單獨包裝，這樣就不能放在一起，所以需要設計拆單規則。
1）為了優化用戶體驗
用戶在下單之后能看到清晰的訂單和物流信息。
2）為了平臺管理方便
在前期大多數平臺的訂單系統和支付系統都是分開設計的，像訂單系統有多個子訂單：訂單A，訂單B，訂單C，當這個訂單支付完了之后會合并在一起，傳入支付系統，那后者看到的只有一個單號，
3）為了后臺的操作靈活度
所謂拆單，一般的是指拆訂單。注意，這里的【拆】不是拆支付流水，為什么?
很簡單，一個訂單可以對應多個商品；這樣的話，就需要把其中某個商品或者某幾個商品進行分組，形成子訂單，形成了一次付款對應多個訂單的情況。
那你就問了，什么場景下才會有拆單？個人有限的經驗告訴我，無非出于兩點：
從圖中可以看出，用戶在付款后需要平臺去判斷該訂單是否需要拆單，怎么拆，這塊要根據自己平臺的業務去制定詳細的規則。
需要注意的是，如果用戶已經生成了訂單但沒有付款，這時該訂單會在待付款展示。注意：這時候的訂單是不拆的，只有在用戶付完款之后才會去判斷拆單流程。
之前的退款邏輯是對一個訂單內的商品進行依次退款，所可能發生的情況。現在如果進行拆單，就涉及前端顯示問題，我們是根據供應商的不同所進行的拆單。前端頁面上會顯示每一個供應商下的商品訂單，也可以看到根據規則拆出來的商品價格。
這里給大家幾個問題思考：
根據自身公司的業務需要怎么拆單？
我的訂單內如果有的商品發貨，有的商品沒有發貨前端怎么展示？
待發貨，待收貨，待評價又怎么展示？怎么根據供應商或者商家進行退款？
拆單后的訂單也是可以查看詳情的，是給用戶展示商品原價，還是展示訂單拆完每一筆的錢這。這里會涉及兩個問題：展示原價時，用戶可能會被搞蒙，不知道自己每筆訂單分別付了多少錢，但底部會顯示實付金額；顯示拆單的價格時，用戶退款是否可以退顯示的商品價錢，這會涉及第一個問題，怎么拆？
訂單號，查看物流，確認收貨，申請退款所對應商品信息以及層級關系，
這里會涉及后臺部分，我們最開始拆單沒有拆訂單號，而是在一個訂單里進行收貨，查看物流和確認收貨的操作，之后因為一些原因就換掉了。這里需要考慮每一個狀態所對應的是后臺的哪部分。
這一塊很復雜，我在之前的文章中總結過一篇電商的退款邏輯，之后的內容可能會跟上一篇文章有關聯。如果大家看完有任何異議的地方可以查看我的上一篇文章，會有些啟發，最后，希望大家能認真看也歡迎大家補充。
寫了這么多，把好多踩過的坑和涉及到的都寫在文章里了。
電商拆單這一塊，涉及的地方很多，大多數情況都需要推倒本身的業務重做。所以，在設計這一部分的時候也要額外注意，否則就要被開發爸爸們群攻了。
最后，希望正在設計這一塊的產品看到這篇文章后能有所啟發。
做電商，必須知道這些退款邏輯
作者：胡子邯；公眾號：產品經理的日常思考。
本文由 @胡子邯 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
