企业官网建设流程全解析

• 桌面应用
• 跨平台
• 前端

导读

本文基于 Readest 项目关于「iOS 连字符断词偏弱」（Issue #5749）的技术调研记录，系统梳理四大渲染引擎（WebKit / Blink / Firefox / WebKitGTK）的连字符（hyphenation）底层词典机制与能力差异，并结合仓库源码（样式注入、选择框边界修复、布局设置面板）说明 Readest 当前的连字符实现方式。读完本文，你将掌握：为什么 iOS 上的断词远不如 Chrome 激进、为什么纯 CSS 无法修复 WebKit 的连字符问题、以及「JS TeX 模式断词 + 软连字符（U+00AD）自注入」这条已被验证的可行路径及其偏移量归一化成本。

问题背景：Issue #5749 与 #4529

Readest 的跨平台排版体验存在一个长期可见的不一致：同一本书在 iOS 上开启连字符后，断词密度远低于 Chrome。Issue #5749（由 #4529 延续而来）正是围绕这一现象展开的专项调研，2026-08-17 在 GitHub issue 中发布了完整的引擎研究结论。调研确认的关键事实是：引擎词典内部机制无法从仓库代码中反推出来，必须依赖对四个渲染内核实现细节的了解，因此该记忆文档的价值在于「避免实现时重新调研」。

项目的核心结论先行给出：

• 各引擎的连字符行为差异来自底层断词词典的算法类型，而不是 CSS 属性支持度的细微差别；
• WebKit 上不存在 CSS-only 修复方案——iOS/macOS 的断词完全由 Apple 密封的系统词典决定；
• 唯一可行的提升路径是：在 JS 层用 TeX 模式断词器生成断点并注入软连字符（U+00AD），让引擎在hyphens: manual下忠实执行；
• 该功能当前状态为OPEN、尚未开始实现，但仓库中已经存在与软连字符打交道的先例代码（Android #1553 的选择框边界修复）。

四大引擎的连字符词典机制横向对比

调研将四个平台的断词实现归纳为两类本质不同的算法：查表型（lookup-based）与生成型（generative）。查表型只会断开词典中收录的已知词汇，专有名词、生僻词、新词永远不会断；生成型基于 TeX 断词模式（Liang 算法）对任意单词进行概率性断点计算，任何词都可能断开。

一个可以立刻得出的推论：「Chrome 能断、iOS 不能断」并不是 Readest 的 bug，而是引擎算法差异的直接表现。调研记录明确指出，这一机制差异正好解释了「Readest-iOS ≈ Apple Books」的观感——两者都走同一个 Apple CF lexicon。

WebKit：密封词典为何让 CSS 无能为力

iOS/macOS 的断词入口是 Core Foundation 的CFStringGetHyphenationLocationBeforeIndex。它背后是 Apple 维护的、随操作系统发布的密封词库（sealed OS lexicon），具备以下特征：

• 查表型判断：只有词库内收录的词才会给出断点位置；未知词、专有名词一律不断；
• 无定制接口：不提供任何 API 向该词库追加或替换自定义词条；
• 忽略现代 CSS 限制属性：WebKit 不识别hyphenate-limit-chars（字符数阈值、前后缀最小字符数均无法通过它控制）；
• 仅有的旧式属性只能做减法：-webkit-hyphenate-limit-before/after/lines只能降低断词密度（限制行首/行尾最少字符数与连续断行数），无法让 Apple 词典断出更多断点。

由此得到本调研最硬的一条结论：在 WebKit 上，不存在 CSS-only 的连字符增强方案。所有希望通过样式表「让 iOS 断得更激进」的尝试都注定失败，因为断词决策发生在样式引擎之外、且不可配置。

Blink：生成型 TeX 模式为何更激进

Chromium 系的断词由 minikin 文本引擎驱动，词典使用 AOSP 打包的.hyb格式 TeX 模式（Liang 断词算法）。与 WebKit 的查表不同：

• TeX 模式是生成型的：模式文件记录的是「字符组合的出现概率」，任何单词都可以通过模式匹配计算断点，因此未知词也能断；
• Chrome 曾在 Mac 上使用 Core Foundation 后端，现已移除——这是 Chrome-mac 断词密度优于 Safari-mac 的直接原因；
• 桌面端词典通过组件更新器（component updater）下发；Electron 默认不带词典（需要确认 WebView2 是否自带）；
• Chrome 109+ 支持标准的hyphenate-limit-chars，可以精确控制断词激进程度。

Firefox 与 WebKitGTK：模式词典的两个样板

• Firefox使用mapped_hyph加载内置打包的 TeX 模式，启用前提是元素具有可解析的lang属性——它依据语言标签选择对应的模式文件；
• WebKitGTK（Linux Tauri）走 libhyphen +/usr/share/hyphen/系统词典目录，是四个平台中唯一允许用户安装自定义词典的路径；代价是系统没有装任何词典时，连字符功能整体失效。

这两者共同证明了 TeX 模式在开源引擎中的可行性：只要把模式数据交给引擎，生成型断词就能达到 BookFusion 级别的密度。

Readest 当前的连字符实现：CSShyphens注入

Readest 已内置「连字符」开关与对应样式注入，先看现状，再谈差距。

设置项与数据类型

• 布局面板中的「Hyphenation」开关位于 LayoutPanel.tsx，绑定data-setting-id='settings.layout.hyphenation'，并在useBookLayout（沿用书籍自身版式）开启时禁用——即连字符开关仅在应用接管段落排版时生效；
• 对应状态字段是 book.ts 中BookStyle接口的hyphenation: boolean，与fullJustification（两端对齐）、lineHeight等同级。

样式注入点

style.ts 的getParagraphLayoutStyles是核心注入函数，它根据设置生成段落级 CSS：

p, blockquote, dd, div:not(:has(*:not(<inline 格式化标签>))) { -webkit-hyphens: auto | manual; hyphens: auto | manual; -webkit-hyphenate-limit-before: 3; -webkit-hyphenate-limit-after: 2; -webkit-hyphenate-limit-lines: 2; } li { -webkit-hyphens: auto | manual; hyphens: auto | manual; }

这里有两个值得注意的细节：

1. hyphens依据设置输出auto（启用）或manual（关闭，即只认显式软连字符）；
2. -webkit-hyphenate-limit-before: 3被硬编码为 3，而WebKit 的默认值是 2——这正是调研记录中「廉价修复（cheap win）」的落点（见下文）。

此外，:is(hgroup, header) p上还会hyphens: unset，避免标题区误触发断词。

仓库里已有的「软连字符感知」先例：#1553 选择框修复

调研记录特别强调：当前src/与foliate-js/中没有任何代码处理 U+00AD 软连字符，唯一与连字符打交道的先例是 Android #1553 的选择框边界修复。这条先例在 sel.ts 中，对未来实现软连字符方案有直接参考价值：

• 问题现象：Android WebView（Blink）在「触摸选中段落首字符」时，会把段内每一个自动断词生成的连字符片段都标记为选择起点，导致原生拖拽手柄被画到段落最后一个连字符上（LayoutSelection::ComputePaintingSelectionStateForCursor对连字符片段的TextOffset处理错误）；
• 检测手段：isHyphenHandleBugProneRange同时检查三种连字符来源——计算样式hyphens: auto、-webkit-hyphens: auto、以及文本内容中包含 U+00AD 软连字符：

const mayHyphenate = style.getPropertyValue('hyphens') === 'auto' || style.getPropertyValue('-webkit-hyphens') === 'auto' || (block.textContent ?? '').includes('\u00ad');

第三项意味着：即使引擎处于hyphens: manual，只要文本自带软连字符，该工具函数同样能识别并修复选择边界——这正是软连字符方案落地时可直接复用的能力；

• 几何判定：hasTrailingHyphenRectPattern通过getClientRects检测「行尾附加一个亚字形宽度（≤ 0.6em）的窄矩形」这一连字符排版特征，且支持横排/竖排两种模式；
• 测试覆盖：完整用例见 sel-hyphen-bounds.test.ts，其中明确包含一段含 U+00AD 的断言：

'Argentina has suf­fered from repeated bouts' // 含软连字符的段落

前进路径：JS TeX 模式断词 + 软连字符注入

调研给出的唯一能对齐 BookFusion 级断词质量的方案分两步：

1. 在 JS 层运行 TeX 模式断词器——调研文档示例性地提到 Hyphenopoly（约 70 种语言，支持配置leftmin/rightmin最小前后缀字符数），在阅读排版前对文本进行断点计算；
2. 将断点以软连字符 U+00AD 写入文本。由于样式注入默认使用hyphens: manual（见上文 style.ts），引擎会把 U+00AD 视为显式断词点忠实执行——manual模式下引擎不做任何自主断词，只尊重文本里已有的软连字符。

该方案在 WebKit 上有效的原理：软连字符是普通文本字符，绕开了密封词典的查表限制，断词决策完全由 JS 层控制，且leftmin/rightmin可配置意味着可以精确调节激进程度，弥补hyphenate-limit-chars在 WebKit 上不可用的缺憾。

必须正视的代价：文本偏移量漂移

软连字符不是布局产物而是真实文本字符，插入后会改变字符串长度，凡是依赖原始文本偏移量的功能全部需要归一化处理。调研明确列出的受影响模块包括：

• CFI 标注：EPUB CFI 按文本节点与字符偏移定位，多出的 U+00AD 会使既有标注偏移失效；
• 全文搜索：搜索索引与高亮定位需要跳过软连字符做等价匹配；
• TTS 朗读标记：朗读位置的标记同样按字符偏移计算；
• 复制与翻译：复制选区、机器翻译取词时需剥离 U+00AD，避免把断词点带进复制内容或翻译请求。

这也是该功能至今停留在 OPEN 状态的原因——断词器本身不难，难在让整条标注/搜索/朗读/翻译链路都感知并归一化软连字符。调研建议的落地顺序是：先从软连字符注入 + 偏移量归一化入手，不要寻找 CSS-only 修复（WebKit 上不存在）。

廉价修复：-webkit-hyphenate-limit-before从 3 放宽到 2

调研记录中给出了一个无需任何引擎改造即可实施的优化（cheap win）：

style.ts的getParagraphLayoutStyles设置了-webkit-hyphenate-limit-before: 3；WebKit 的默认值是 2，因此我们这条 CSS 反而让 iOS 比原生 Safari更保守。在启用连字符时应放宽到 2。

含义拆解：

• -webkit-hyphenate-limit-before: 3要求断点前至少保留 3 个字符，WebKit 默认只要求 2 个。Readest 的硬编码值在 WebKit 上主动提高了断词门槛，比用户直接使用 Safari 阅读时断词更少；
• 在 WebKitGTK 等其他引擎上该属性无副作用，因此放宽到 2 属于零风险的收益项；
• 建议与hyphenate开关联动：仅在连字符启用时输出2，避免在manual模式下产生无关影响。

结论与实现清单

围绕 #5749 的技术事实可以总结为一张实现检查表：

1. 不要试图在 WebKit 上找 CSS-only 修复——断词由 Apple 密封词典决定，hyphenate-limit-chars在 iOS/macOS 无效；
2. 目标方案是 JS TeX 模式断词器 + U+00AD 注入，利用现有hyphens: manual注入让引擎忠实执行；
3. 先解决偏移量归一化：CFI 标注、搜索、TTS、复制/翻译四条链路都要能感知并剥离 U+00AD；可参考 sel.ts 中已有的 U+00AD 检测先例及其 测试用例；
4. 顺手执行廉价修复：将 style.ts 中的-webkit-hyphenate-limit-before由 3 放宽到 WebKit 默认的 2，消除「Readest 比 Safari 更保守」的现状。

引擎词典的内部机制无法从仓库反推，但只要理解了「查表 vs 生成」这一根本分界，跨端断词不一致就不再是谜题，而是一份可以执行的工程路线图。

• 桌面应用
• 跨平台
• 前端