在圖文密集的界面裏，長單詞或複合詞一旦撞到容器邊緣，要麼整塊被擠到下一行，要麼被粗暴地從任意位置截斷，這兩種結果都很傷排版。Hyphenation 的目標，就是讓控件在多行換行時，按語言學的音節或詞法規則把單詞切分，並在行尾展示一個連字符，從而兼顧可讀性與版式緊湊度。CSS 把這件事抽象成 hyphens 這樣的屬性，瀏覽器在具備對應語言詞典時就能自動完成；當原生能力不足時，可以用軟連字符或腳本庫做兜底。MDN 的解釋很直白：hyphens 屬性決定當文本換行穿過單詞時，是否以及如何進行連字符分詞，既可以完全禁止，也可以完全交給瀏覽器自動處理，或只在手動標記的位置斷開。(MDN Web Docs)

從標準角度看，W3C 的 CSS Text Level 3 把 hyphenation 定義為一種軟換行機會，是否允許在詞內部斷開由 hyphens 控制；規範不強制規定各語言的具體斷詞規則，而是鼓勵用户代理按語言優化斷點選擇。這意味着不同瀏覽器、不同語言包，呈現會有差異。(W3C)

為了讓控件的 Hyphenation 真正發揮作用，有兩個容易被忽略的前提。其一是語言環境：瀏覽器通常需要靠 HTML 的 lang 來選擇正確的斷詞詞典；很多開發者以為加了 hyphens:auto 就萬事大吉，結果長德文詞依舊不分。這是因為缺了 lang='de'，或瀏覽器沒有內置該語言的詞典。(WIRED) 其二是兼容性和細化控制：現代瀏覽器開始支持 hyphenate-character 去自定義斷行處顯示的字符，hyphenate-limit-chars 用來限制被斷詞的最小長度與斷點兩側的最少字符數，不過這兩者的覆蓋面並不完全一致，使用前務必核對支持矩陣。(MDN Web Docs)

在企業級前端框架裏，Hyphenation 通常被包裝成控件屬性。比如 SAP UI5 的 sap.m.Text 和 sap.m.Title 在 wrappingType 設為 Hyphenated 時，會在換行時按語言規則斷詞並顯示連字符；設計規範也明確説明該能力會在有詞典支持的語言上生效，用以改善多行標題與卡片標題的可讀性。(SAP)

為什麼 Hyphenation 比 overflow-wrap 或 word-break 更優雅 overflow-wrap: break-word 或 word-break: break-all 屬於版式保底，它們不考慮語言學的音節或複合詞結構，只是為了防止溢出，讓字符串在任意位置或自然機會處分裂。文章深入比較了這幾種方式的差異：overflow-wrap 傾向優先保持單詞不被拆開，逼不得已才斷；word-break: break-all 則幾乎可以在任意字符間斷開，尤其會傷害 CJK 以外語言的可讀性。(codersblock.com)

Hyphenation 不僅避免了粗暴斷詞帶來的閲讀割裂，還能減小段落的鋸齒邊緣，讓長段文字在窄列裏更像傳統出版物的排版效果。早期實踐文章就強調，瀏覽器一旦帶上語言斷詞詞典，配合 hyphens:auto 就能顯著提升正文可讀性，並且對不支持的瀏覽器不會造成壞影響。(WIRED)

工程師需要掌握的三個關鍵點

• 語言與詞典 控件要想自動斷詞，lang 必須正確，且瀏覽器需要有相應語言的 hyphenation 詞典。缺任一條件，hyphens:auto 可能像沒開一樣。(WIRED)

• 策略與細化 除了 hyphens 本身，現代 CSS 還提供 hyphenate-character、hyphenate-limit-chars 等細化開關，以控制行尾顯示的符號和斷詞的最小長度、前後保留字符數量。不過目前它們在不同引擎的支持度不一，上線前應該結合 Can I use 檢查並做降級策略。(MDN Web Docs)

• 手動提示與兜底 對專有名詞、路徑、長 URL 或瀏覽器詞典覆蓋不到的語言，可以用軟連字符 U+00AD，即 HTML 的 ­，在詞內埋下可斷點；若僅僅需要允許中間斷而不出現連字符，可考慮 <wbr>。MDN 指出 ­ 在行尾會顯現連字符，而 <wbr> 斷行不加連字符。(MDN Web Docs)