題幹與適用場景
國際化內容站的卡片標題在窄螢幕上只剩一個詞，長段落末尾也經常出現孤行。設計團隊希望統一使用一行 CSS 修復，但頁面還要支援使用者編輯、舊瀏覽器和動態字型。請比較 text-wrap: balance、text-wrap: pretty、普通 wrap 與 stable，給出選擇依據和落地方案。
這道題適合前端、設計系統和內容平台職位。重點是理解文字換行是版面行為，不能把視覺偏好誤當成固定寬度或 JS 測量結果。
面試官考察點
強回答會把 balance 用在短標題、引用等少量行數的文字，把 pretty 留給較長的正文並承認其較高計算成本；會說明兩者都不改變元素的內聯尺寸，也不會自動解決 white-space: nowrap。還應涵蓋 stable 對 contenteditable 編輯體驗的價值、多語言測試、舊瀏覽器靜態降級和可及性。
回答前需要釐清的問題
- 文字是標題、卡片摘要、正文還是可編輯輸入區？預期最多幾行？
- 需要避免孤行，還是需要讓每行視覺長度更均衡？
- 容器是否已有
white-space、固定高度、截斷或line-clamp？ - 目標語言、字型載入時機和瀏覽器支援矩陣是什麼？
- 舊瀏覽器必須保持相同斷行，還是可接受普通換行的漸進降級？
30 秒回答框架
「我會先按內容類型選策略：短標題用 text-wrap: balance，正文若確實需要減少孤行再評估 pretty，普通內容維持 wrap，可編輯區域考慮 stable。這些屬性改變軟換行，不改變元素寬度；white-space: nowrap、固定高度和截斷仍需單獨處理。先保留可讀的預設樣式，再在支援的瀏覽器啟用增強，並用多語言、字型載入、響應式和編輯場景做視覺與效能驗證。」
分步驟深入解答
第一步：區分四種策略
wrap 允許瀏覽器按正常斷行規則換行；nowrap 則關閉軟換行。balance 嘗試讓短文字的各行長度更均衡，適合標題和引用。pretty 使用較慢演算法改善較長文字的換行，並重點減少孤行。stable 面向 contenteditable，讓游標附近編輯時之前的行盡量保持穩定。
第二步：給標題設定可控邊界
平衡演算法需要文字真的有機會換行。為標題設定 max-inline-size 或合理容器寬度，再套用 text-wrap: balance；否則單行文字沒有可平衡的候選。不要用手工 <br> 標籤固定英文或中文斷行，因為翻譯、字型和螢幕寬度會改變結果。
.card-title {
max-inline-size: 24ch;
text-wrap: balance;
}第三步：謹慎使用 pretty
pretty 適合正文、說明和較長引用，但它比普通換行需要更多計算。只在文字品質確實重要且文字長度足夠時啟用，避免寫在全域萬用選擇器上。對只有一兩行的標題，balance 更直接。
第四步：處理 white-space 和截斷衝突
white-space: nowrap 明確要求不換行，與 balance 的目標衝突。要啟用平衡換行，先移除或覆寫 nowrap。固定高度、overflow: hidden 和 line-clamp 仍會裁切內容，需在設計上決定是允許高度增長、顯示省略號，還是提供完整文字。
第五步：理解效能邊界
瀏覽器需要嘗試不同斷行方案。MDN 和 Chrome 文件都建議把 balance 限制在短文字，較長正文才考慮 pretty；不要憑感覺聲稱屬性一定比 JS 快。用真實頁面測量版面、字型載入和長列表渲染。
第六步：覆蓋多語言和字型變化
同一標題在中文、英文、德文和阿拉伯文中會有不同斷行機會。測試應覆蓋語言切換、字型回退、字級放大、窄螢幕和寬螢幕。不要以某一種語言的快照斷行作為契約；契約應是不溢出、可讀、層級穩定和內容完整。
第七步：為可編輯內容選擇 stable
contenteditable 中使用者修改中間文字時，整段文字重排會讓游標附近的行跳動。text-wrap: stable 可讓編輯位置之前的行保持穩定，但它不是標題美化策略，也不會取代輸入框高度管理。只在確實存在編輯體驗問題的區域啟用。
第八步：設計漸進增強和驗證
預設樣式使用普通 wrap 與可增長高度，支援的瀏覽器再加入 balance 或 pretty。使用能力檢測或 CSS 規則分層，不要讓關鍵內容依賴增強屬性。驗證計算樣式、溢出、CLS、長列表耗時、字型路徑以及讀屏順序。
設計取捨與邊界
balance 改善短文字的視覺節奏，但不會縮小元素寬度；卡片邊框、陰影和對齊仍由容器決定。pretty 可能提升正文排版，也可能增加版面成本。兩者都不取代內容編輯、斷詞規則、overflow-wrap 或可及的全文展開。
不要把瀏覽器目前支援情況寫成永久保證。CSS Text Level 4 仍有實作差異，必須按產品支援矩陣驗證。對關鍵標題保留普通換行可用路徑，對不可見或裁切的文字提供可及名稱和展開方式。
落地計畫與證據
先挑選標題、摘要和正文各一個元件，記錄語言、最大行數、容器尺寸和字型狀態。標題試點使用 balance，正文只在孤行問題可重現時試用 pretty，編輯器單獨評估 stable。在 Chromium、Firefox、Safari 和目標舊版瀏覽器中檢查溢出、版面偏移和輸入游標穩定性。
把規則寫入元件文件：內容類型、最大行數、white-space 前置條件、降級樣式和測量指標。每次修改字型、容器寬度或翻譯都執行視覺回歸，避免以單一快照掩蓋多語言斷行回歸。
常見誤區與追問
對所有元素使用 balance
全域套用會浪費計算，也無法改善長正文。把它限制在標題、引用和確實需要平衡的短文字。
以為 balance 會改變元素寬度
它只改變軟換行，不會讓盒子自動收縮。卡片的內聯尺寸仍應由版面和 max-inline-size 決定。
忽略 nowrap 或固定高度
這些規則可能讓文字繼續溢出或被裁切。先檢查計算樣式，再決定是否允許換行和高度增長。
把 pretty 當成無成本的孤行修復
更好的換行需要額外計算。應以真實長列表和低端裝置測量，而不是只看單個示例。
可編輯區域為什麼不用 balance？
編輯時重排可能讓游標附近跳動。若問題是編輯穩定性，應評估 stable；若問題是標題視覺，應在唯讀展示層使用 balance。