在互聯網產品的研發過程中，頁面的視覺恢復是一個非常重要的步驟，通常是一個有很多問題的環節。如果在這個鏈接中沒有有效地發現和解決一些細節，那么在后續過程中解決這些問題的成本將呈指數級增長。

所以今天我們來梳理一下前端工程師本身和上下游角色之間容易遇到的常見問題。

設計師

設計師是接近產品體驗的人，但專業從事藝術行業，設計師往往更注重視覺表現，容易犯一些美麗的錯誤：

1，以原生APP的體驗類比H5頁面設計

眾所周知，原生APP體驗非常流暢，界面也非常華麗，所以設計側也試圖出身APP接近體驗。但現實往往很殘酷，很多APP的體驗換到H5.實現是可怕的，比如一個包含復雜操作的浮層，可以說是各種低端機器的漏洞。所以這里，建議設計師可以多比照其他H設計網站的性能，而不是經常比較APP的體驗。

2.設計稿處于狀態

是的，設計草案通常反映了所有的狀態。而前端開發人員往往要考慮各種溢出狀態，多個超出、折疊、開放等。這些情況大多不會反映在設計草案中，通常需要在開發過程中確認細節，這是浪費時間。

3.活字使用非系統字體

所謂活字，就是直接以文字的形式顯示在頁面上，而不是用圖片模擬的文字。對于這部分字體，我們通常使用系統字體中的一個，不會因為幾個特殊字體而加載一套中文字體文件。如果是英文字體，也可以考慮高級瀏覽器下的自定義字體，但也要考慮優雅降級和字體版權。所以老板問:毛和設計稿不一樣嗎？我們只能說沒有這個字體。...這里建議，即使是設計稿，活字也要用系統字體，否則就是坑，看起來好看，實現不了。

4.版本不清楚

設計的手稿通常是一段時間的規劃功能，然后與產品確認。產品通常會說，這不是第一個，那不是第一個。但當真正刪除時，所有這些間距調整、顏色背景影響等，或與設計師確認。所以如果可能的話，每個需求都應該只突出變化部分，而不是一個大而完整的手稿。

5.這個應該這樣切

關于這個問題，我已經無法吐槽了。這個頁面真的不是切出來的。你說這么切那么切，你給我看嗎？顯然是滾出來的~

前端開發

前端開發，又稱頁面仔、切圖仔，在還原設計的過程中，容易遇到更多的問題：

不考慮溢出

這里有一個基本的溢出規則，即只要是動態輸出內容或用戶輸入，就必須考慮溢出狀態的顯示。文本溢出、列表溢出等。當獲得設計草案并確認布局時，確認各種溢出狀態。

2.不分析設計稿析設計稿

作為一個新手，在獲得設計草案后，他經常想快速編寫代碼，因為編寫代碼有樂趣。眾所周知，頁面結構的分析與程序架構一樣重要。只有通過徹底的分析，我們才能考慮到各種情況和一些需求變化。所謂磨刀不誤砍柴工，必須先做結構分析。

3.不考慮增刪元素的狀態

稍大一點的公司往往有多個平行的需求，所以設計草案可能有先進的部分，或由于各種原因無法實現的功能。作為一名合格的前端工程師，在實現頁面時，即使刪除了可能的部分，也不會對頁面產生很大的影響。

不考慮可維護性

為了應對需求變化，盡應需求變化的地方。例如，調整多層的寬度，增加一層icon等等。舉個簡單的例子，比如框架中間有一個中間按鈕，很多新手直接用margin-left這樣，如果調整外框的寬度，就可以定位margin-left值得調整。雖然調整寬度并不麻煩，但當開發大型復雜頁面時，這些聯動的小變化就足以殺死人。

5.不要仔細看設計稿

常見的錯誤是設計草案上有一個框架，但顏色太淺，看不見?；蛘咴O計草案沒有框架，由于迭代風格，添加了深色背景，忽略了框架沒有被刪除。另一種情況是，設計草案上的色塊覆蓋了邊線，但沒有覆蓋，導致那部分看起來凹陷。

6，看出1px沒那么難

很多新人覺得對齊1px差距太難了，聽起來有點挑剔。但想想看，如果你是一個設計師，努力制作一個設計草案，到處都對，你不會感到不舒服嗎？事實上，只要你仔細看，再加上一些練習，幾乎一眼就能看到幾乎像素。真的感覺不確定，你可以截圖PS放大內部，然后用參考線進行比較。

7.不考慮可擴展性

大多數時候，我檢查頁面恢復，只是添加更多的項目，填寫更多的文本來嘗試，但很多人不能通過這個水平。添加一個項目，要么在多行時沒有設置下邊距，要么更多的邊界改變，要么在項目的結尾設置一個單獨的風格。添加文本，直接出去破壞結構。

好了，吐槽這么多大家肯定夠了。相信大家在工作過程中都會遇到各種細節，還有一些問題一遍又一遍的遇到，比如突然急著跑來跑去:這個頁面怎么亂？~~~答：ctrl0，你放大了...So，你有什么要吐槽的嗎？