1樓：Tux ZZ
我的實踐中大部分元素用in，少量細小元素用px。
因為in單位導致的非整數畫素的問題，雖然高分屏上一般不是問題，但是低分屏+細線條就是地獄了。所以用in這種物理尺寸來說更加直觀，px這種邏輯單位方便控制一些細小元素的尺寸。
我知道目前裝置上的px全是邏輯畫素，然而邏輯畫素縮放比例參差不齊，想控制實際顯示尺寸單靠px是很困難的。通過in單位+media query，我可以較為準確地控制在每種型別的螢幕上我的網頁的尺寸外觀，而不會受到各種稀奇古怪的縮放比的影響。
2樓：水映天轍
作為阿里系，px2rem規則制定的參與人之一，我回答一下rem的來龍去脈：
大家別長篇大論的寫rem和px的比較了，用rem替代px最根本的目的不是適配和縮放，是為了讓1px是實現1物理畫素，是為了讓1px是實現1物理畫素，是為了讓1px是實現1物理畫素！！！重要的事情說三遍，怕你們真的記不住！
根本的起源：
rem替代px的原因是設計師要求h5跟native一樣實現border的1px，作為設計師出生的前端開發，我是很能理解為什麼有這個訴求的，也是因為這個訴求完成以後，才讓大家無法辨別頁面是h5寫的還是native寫的；
簡要的過程：
有兩種模式「flex」和「vw」，都只是對font-size的計算規則不同，後者是真等比縮放，通常產品頁面用flex，活動頁面用全等比縮放的vw模式；
我們實際在less裡面都不寫rem；而是通過打包工具把px換算成rem。換算邏輯你們如果仔細研究過的話會發現，我們特地把1px保留成1px輸出，而不是0.01rem的方式輸出；
另：這個問題不要在爭吵了，在vw和0.5px全相容之前，大家都乖乖用rem吧！！！
3樓：湯小洋
px是用於固定尺寸的單位，多用於pc端頁面；而rem是乙個相對於html根元素的單位，適合用於簡單的移動端頁面。在專案中還是要根據具體開發要求來選擇最適合的長度單位。
px
px意為畫素，它是相對於顯示器螢幕解析度而言。用px設定字型大小時，效果會比較穩定和精確。但是用px也存在一些問題比如：
IE瀏覽器無法調整那些使用px作為單位的字型大小，因此會造成因裝置螢幕大小使得頁面效果發生改變。
rem
rem是CSS3新增的乙個相對單位，當使用rem為元素設定字型大小時，它會相對於HTML根元素是。通過rem，我們只需要修改根元素就可以成比例的調整所有字型的大小，同時還可以避免字型大小逐層復合的連鎖反應。
px與rem如何選擇
px適合用於固定尺寸，多用於pc端頁面，而rem更適合用於移動端頁面。
rem實現的是在不同尺寸的螢幕上顯示大小一樣的內容，但是使用者往往需要的是頁面效果隨著螢幕的大小改變而改變，所以rem在複雜的頁面上不佔任何優勢。
所以在開發中，我們還是要根據實際開發情況來決定，比如有的專案只需要在pc端展示我們就可以使用px作為長度單位，有的專案需要做響應式開發就要看具體情況來決定了。
4樓：j小鑫
為什麼不用rem呢？
pc端的web專案自然是用px，這個沒有爭議。但是移動端的專案rem確實能很好的適配各種尺寸的螢幕呀！
我說一下我這麼說的原因，估計很多前端開發情況和我差不多。
ui在做設計稿的時候都是按iphone6的尺寸設計的。如果用px做單位的話，大屏的手機上會顯得特別小，使用者用著非常難受。我公司之前有個專案就是用px做的移動端頁面，很多使用者抱怨頁面看著非常累。
之後我吧幾個頁面改用rem的，給幾個使用者體驗了之後明顯反饋舒服多了。
還有兄弟提到了，有些前端和ui比較懶不願意去適配各種尺寸的螢幕! 不得不承認，確實是這樣，我也是乙個很懶得前端。但是用簡單的rem就能適配各種移動端螢幕何樂而不為呢？
5樓：chocolatl
rem的定義就是相對根元素字型大小的單位，首先它是乙個相對單位，但不是作用於布局的。只不過在vw這個作用於布局的相對單位還沒普及之前，被當作一種替代方案，也就是通過JS動態獲取視口寬度設定根元素字型大小使得rem達到類似vw的效果而已。但很多前端都是依葫蘆畫瓢，跟著一起使用rem，所以rem成了一種常見的布局選擇
vw或rem實現等比縮放自適應，通常是在移動端各種手持裝置尺寸不一但是尺寸差距不大情況的一種常見解決方案，對於桌面端或者響應式布局，強行rem或vw沒必要
CSS中有很多長度單位，每種都有自己獨特的意義，不可能存在整個專案只使用px/rem之類的情況，你希望乙個側邊欄固定寬度，那就用px；希望元素相對父元素寬度，就用%；希望元素相對於視口寬度，就用vw...
6樓：TedLin
我就知道用相對單位em rem等，在不同裝置和瀏覽器上不了避免的會出現畫素抖動的現象，即畫素位置很難100%到精確到點上，甚至出現邊緣渲染模糊的現象，更不用說有的同學的em和rem還是除不盡的數值了。在很多需要精確定位的案子上就很難辦。px就沒有這個問題，肯定很精確。
7樓：crixusshen
Rem那麼好的特性為什麼不用，我們公司所有專案都使用rem，而且viewport是根據視口大小動態計算，實現高清屏方案。移動端的頁面px無法做到適配，特別是安卓這塊。
8樓：石頭哥
請教各位，我看到別人vue移動端專案用的，設定最大寬度，連著vw和vh一起用，就能實現所有螢幕布局都是一致的，這個有啥問題沒？
9樓：Exception.neko
1rem = dom根節點字型尺寸
比如body上有個font-size = 14px那1rem就等於14px
如果要把整個前端視覺放大，那就改一下body的font-size，整個前端尺寸就跟著變了
大多數前端設計稿都是固定尺寸的，顯示器最小畫素單位就是1px，你沒辦法也沒必要用rem精準描述px，直接用px能解決的問題，你還得拿計算器做除法
10樓：ChuckieChang
沒有最好，只有更合適。不論是啥主流框架，它們並不是一種單位標準，前端視覺一直會根據變化和專案來做微小的習慣改變，我自己的目前的習慣：某些地方使用px比較合適，比如一些Web Font或者某些特殊部位的margin,padding的控制；某些地方使用em來做相對計算，會比較省事，比如H1,H2裡面嵌入的一些大小；大部分地方，我會統一使用rem，特別是文字大下的控制，因為由乙個根大小來控制全域性，方便整體上的自動適配，適應不同的專案（重複使用一套可靈活修改的標準）。
下面的乙個截圖是我常用的一種配置：
下圖是用某些地方使用em時候的一種情況
上門截圖僅僅是簡單舉例，不要死板的認為用px還是rem還是em還是vh，vw，還是要根據具體的應用場景，靈活程度，思路邏輯等等，總之，高質量高效率，甚至便於後期維護和重用，達成目的就OK。
11樓：
其實光用px和vw還有calc就能很好的處理字型responsiveness的問題，而且不用寫一堆media query
calc(42px + (60 - 42) * (100vw - 768px) / (1440 - 768));
上面的等式，最大最小字型隨便調，再額外寫倆media query，把1440+和768-的字型寫死就好，純css
當然，等式寬度也可以隨便調
另外用rem處理字型的問題我覺著在本質上和寫死px沒有任何區別，你同樣是給乙個固定的值，一樣要用media query，唯一的區別就是它多算了一步， 從某種意義上說甚至不如寫死的px
另外用vw處理字型responsive的問題在於你無法確定比例尺，比如你需要乙個字型在桌面上60px，手機42，但是如果你桌面60是5vw，你在mobile上5vw很可能非常小，導致總要用一堆media query來處理在特定解析度下字型過大或者過小的問題。
使用上面的等式就不會有這種問題
12樓：方應杭
聽話不要聽一半，
本來就應該是
布局用 rem、vw
內聯元件用 px、em
尤其是開源元件，如果你的元件寫 width: 14rem，鬼才會用你的元件……
13樓：一波不是一波
px 多用在 pc web 頁面
rem 是為了在移動 web 頁面和設計圖中間做單位轉換用的但是不代表移動 web 頁面上所有單位都要用 rem，字型大小還是 px 合適。
還有 2019 了，不要用 rem 了吧，該 vw 了。
14樓：Belleve
早年（大概就是 div+css 這個詞還流行的時候），css 裡面用 em 大量代替 px 是因為，早期 IE 和火狐沒有整頁放大，只能改基礎字型大小……
15樓：TinaLim
回答更新
看到大部分崇尚px的，感覺很可悲，都2023年了，就不能自己去證實一下麼？人云亦云，都把焦點放在單獨使用px，單獨使用rem身上，難道就不能怪個彎想想remem麼？？？？？
我不知道耶，專案如果要求響應式我就會用emrem，不要求就px
為什麼對比 Fireworks，更多人使用 Photoshop 和 Illustrator 做使用者介面設計？
江健力 原因1.可替代產品市場成熟 像Photoshop，用的人最多，用Photoshop的人把Photoshop用的好的人也多，其實這幾個軟體很多重疊性，所以Photoshop可以完成使用者介面設計，而Photoshop的人又好招。會Fireworks的人少，並且招過來幾乎只能用於網頁設計 原因2...
為什麼奧運射箭專案不准使用複合弓？
謙生 因為複合弓的輔助裝置過多，幾乎中和了訓練的結果了。下面來看看。目前國際奧委會承認的唯一射箭形式是反向弓。然而，複合弓更接近於奧運賽場上出現的倒弓。因為最近，國際射箭聯合會宣布複合弓將於2019年進入泛美運動會。受到泛美運動會等許多大陸錦標賽的承認，複合弓進入奧運會是乙個重要的步驟。你們會很興奮...
為什麼很多OIer ACMer不使用vector而使用陣列？
慢。類似的問題還有 為什麼不用set map替代平衡樹 申請新空間的速度真是感人。類似的習慣還有 寫線段樹之類的時候，先建乙個記憶體池，新建節點的時候直接從裡面取，不要申請新的單元 vector最大特性就是動態長度，也就是自動擴容。用不上這個特性的話可以直接退化為new個陣列。至於為什麼用陣列不用n...