在互聯網產品的研發流程中，頁面的視覺還原是很重要的一個步驟，也往往是問題多的一個環節。如果一些細節問題在這個環節沒有被有效地發現並解決，那麼後續流程中再去解決這些問題的成本就會呈指數上升。
那麼今天我們就來梳理一下，看看前端工程師本身以及上下游的角色之間，都會容易遇到哪些常見的問題。
設計師
設計師是貼近產品體驗的人，但是術業有專攻，設計師往往更加註重視覺的表現，而容易犯一些美麗的錯誤：
1，以原生 WordPress APP 的體驗類比 H5 頁面設計
我們都知道，原生 WordPress APP 的體驗非常流暢，介面也非常華麗，所以設計側也儘量向原生 WordPress APP 的體驗靠攏。但是現實往往很殘酷，許多 WordPress APP 的體驗換到 H5 上實現就慘不忍睹，比如一個包含複雜操作的浮層，在各種低端機上可以説是漏洞百出。所以這裏，建議設計師可以多比照其他 H5 網站的表現來進行設計，而不要經常比照 WordPress APP 的體驗。
2，設計稿都是的狀態
是的，設計稿上面往往體現的都是的狀態。而前端開發人員往往要考慮各種溢位狀態，多個超出、折行、撐開等等。這些情況多數在設計稿上不會體現，往往要到開發過程中再去確認細節，比較浪費時間。
3，活字用了非系統字型
所謂活字，就是直接以文字形式展示在頁面上，而不是用圖片模擬的文字。對於這部分字型，我們一般會採用系統字型中的一種，不會因為幾個特殊字型而去載入一套中文字型檔案。如果是英文字型，還可以考慮在高階瀏覽器下的自定義字型，不過也要考慮優雅降級，以及字型的版權問題。所以老大問：為毛跟設計稿不一樣？我們只能説，沒這字型啊… 這裏建議，即使是設計稿，活字也要用系統字型，否則就是坑啊，看着好看又實現不了。
4，版本不清晰
設計出的稿子，往往是一段時間的規劃功能，再去跟產品確認。而產品一般會説，這個先不要，那個先不做。但當真正去掉之後，所有這些間距調整，顏色背景影響等等，還是要再跟設計師確認。所以如果可能的話，應該每次需求只突出變更部分，而不是一個大而全的稿子。
5，這個應該這麼切
關於這個問題，已經無力吐槽了，這頁面真的不是切出來的。您説這麼切那麼切，您切個給我看看？分明是擼出來的嘛～
前端開發
前端開發，也有稱頁面仔，切圖仔，在還原設計的過程中，容易遇到的問題就更多了：
1，不考慮溢位
關於溢位這裏有個基本的法則，就是隻要是動態輸出內容，或者有多用户輸入的，就一定要考慮溢位狀態的展示。文字溢位，列表溢位等等。當拿到設計稿時，確認好佈局之後，就是各種溢位狀態的確認了。
2，不分析設計稿就動手寫代碼
作為新手拿到設計稿之後，往往都想很快寫代碼，因為寫代碼才有快感。殊不知，頁面結構的分析就跟程序架構一樣重要，分析透徹才能兼顧各種情況以及部分的需求變更，所謂磨刀不誤砍柴工，結構分析一定要先做的。
3，不考慮增刪元素的狀態
稍微大一點的公司，往往是多個需求並行，所以設計稿可能有超前的部分，或者中間由於各種原因實現不了的功能。作為一個合格的前端工程師，在實現頁面的時候，就要做到一些可能變動的部分就算刪掉也不會對頁面造成大面積影響。
4，不考慮可維護性
能自適應的地方儘量用自適應，以便應付需求變更。比如多個樓層，寬度調整，加個 icon 等等。舉個簡單例子，比如一個框框中間有個居中的按鈕，很多新手是直接用 margin-left 來定位的，這樣如果外層框框寬度調整，這個 margin-left 值就得跟着調整。雖説調個寬度也不麻煩，但是當開發大型複雜頁面的時候，這些聯動的小改動也足夠搞死人了。
5，不仔細看設計稿
常見的錯誤就是，設計稿上有邊框，但是顏色太淡沒看到。或者設計稿沒邊框，由於迭代樣式，加了深色背景，忽略了邊框沒有去掉。還有一種情況就是設計稿上的色塊是蓋住邊線的，但是實現的時候沒有蓋住，就導致那一部分看起來像凹進去一樣。
6，看出 1px 沒那麼難
很多新人都覺得要對齊 1px 的差距好難，聽上也有點吹毛求疵了。但是您想想，假如您是設計師，辛辛苦苦做出來個設計稿，哪哪都對不齊，您不會覺得不爽？其實只要您認真仔細看，再加上一些練習，差幾畫素幾乎一眼就可以看出來。實在不行感覺不確定，可以截圖到 PS 裏面放大，再用參考線對比。
7，不考慮可擴充套件性
很多時候我檢查頁面還原，無非是多加幾個專案，多填些文字先試試看，但是很多人這一關都過不了。加了專案，要麼就是沒有設定多行時候的下邊距，要麼就是再多一行邊框變了，或者結尾的專案又要單獨設定樣式。加了文字，就直接頂出去毀了結構。
好了，吐槽這麼多大家一定已經夠了，相信大家在工作流程中都會遇到各種各樣的細節問題，還有一些反反覆覆一遍又一遍遇到的問題，比如忽然一陣捉急的跑來：這個頁面怎麼亂了啊啊啊，麻煩快看看~~~答：ctrl+0，您放大了…… So，您有沒有什麼想吐槽的呢？