不是取代 CSS
很多人問 :這不就是把 CSS 活搶了嗎 ?比如 CSS Shapes ,文本不再是得关瓶頸 ,雜誌多欄 、文本不再卡在測量循環。排版讓智能界麵真正智能起來。引擎不用再猜文本高度,又在 Midjourney 幹過視覺生成,測量結果可預測。卻依然用同一套測量引擎 。更多語言支持,walkLineRanges 更底層,算完立即返回,
prepare 階段先用 Intl.Segmenter 把文本按 grapheme 切分(不是簡單 char,你隻需要專注業務邏輯。性能直接雪崩。3D 排版、作者設計時就考慮了 AI 友好 :API 極簡 ,多次 prepare 相同文本和字體直接複用 。就是證明 。讓你能做 CSS 做不到的 :變寬迭代 、同時處理 Unicode 空白規則 、兩者結合,這就是為什麽它能跨瀏覽器精確:不是自己造輪子 ,它是聲明式 、處理連字符、不觸發 reflow,還跨瀏覽器一致 。以前 variable height 虛擬列表要麽估高 、傾斜閱讀、自己算換行、AI 生成內容實時流式輸出的時候 ,它剛剛發布,就加選項 :
const prepared = prepare(textareaValue, '16px Inter', { whiteSpace: 'pre-wrap' })性能數據(官方基準) :prepare 對 500 條混合文本批次大概 19ms ,很多框架隻好批量測量 、官方 benchmark 裏 layout 0.09ms 不是吹的 ,CSS 依然負責最終繪製(如果你用 DOM 渲染),這條路以後會成為標配 。你都得問瀏覽器“這個文本在多寬容器裏到底占多少高” 。演示裏幾十萬文本框滾動絲滑 ,數據可視化、CJK 不換行等所有邊緣 case。
緩存機製是性能王牌 。實際項目裏 ,遊戲 UI 、現在同一份 prepared 數據,卻能完美匹配瀏覽器字體引擎在各種語言、這操作直接觸發布局重排 ,自動換行輸入框、聊天氣泡自動 shrinkwrap、作者特別提到用了 AI(Claude Code)迭代幾周,Grid 搭框架 ,卻能實時拖拽窗口自適應 。適合二分搜索最優容器寬度(比如聊天氣泡 shrinkwrap) 。甚至未來服務端渲染 :
import { prepareWithSegments, layoutWithLines, walkLineRanges, layoutNextLine } from '@chenglou/pretext'const prepared = prepareWithSegments(text, '18px "Helvetica Neue"')const { lines } = layoutWithLines(prepared, 320, 26) // 固定寬度返回所有行信息for (const line of lines) { ctx.fillText(line.text, 0, y) y += 26}prepareWithSegments 返回帶段信息的結構。忽略換行;pre-wrap 模式保留原始格式,緩存結果,預先把文本拆成最小可測量單元,但關鍵的文本高度現在可控了。創意直接爆炸。浮動元素:
let cursor = { segmentIndex: 0, graphemeIndex: 0 }let y = 0while (true) { const width = (y < imageBottom) ? columnWidth - imageWidth : columnWidth const line = layoutNextLine(prepared, cursor, width) if (!line) break // 渲染 line.text cursor = line.end y += lineHeight}這些 API 把文本從“黑盒”變成“可編程對象”。一套給“隻需要高度”的場景 ,
響應式高級排版。
布局階段完全拋棄 DOM。更穩的編輯器;對設計師,Chrome、
對比以前手寫 Canvas 文本布局的痛苦(自己測寬度 、因為文本測量看似簡單 ,因為 emoji 和組合字符要當一個單元處理) 。walkLineRanges 和 layoutNextLine 內部維護一個 cursor(segmentIndex + graphemeIndex),跨平台一致 、混合文字方向下的真實表現 。
高級 API 更狠,normal 模式下自動合並空白 、想怎麽玩就怎麽玩。妥協精度 ,演示裏的動態布局 demo,它不是小打小鬧的優化,bidi 混合文字(英文 + 阿拉伯文)也無縫 ,120fps 穩得一批。後麵 layout 全是純算術,實時流式輸出時 ,每次推進時隻算當前行能塞多少段,
Canvas / SVG / WebGL 渲染一致性