阅读笔记里的高亮标注，本质上是在原始文本流上圈出若干个区间，然后给这个区间附加颜色、笔记、标签等属性。这个模型看起来简单，但在存储层需要同时考虑区间查询、版本变化、全文搜索和同步冲突。如果只是把标注序列化成一个JSON数组塞进某个字段或文件，当某本书积累到几百条标注后，按章节读取或按颜色过滤都会退化成全量扫描。SQLite很适合承担这个角色，它不用单独部署服务，事务和索引能力足够支撑中等规模的本地阅读数据。
高亮标注的数据特征与存储目标
一条高亮至少有四个基础属性：它属于哪本书、哪个章节、从哪个字符位置开始、到哪个字符位置结束。真正麻烦的是，原始文本可能会变化。比如电子书更新了版本，某个段落的文字被调整，原本保存的字符偏移就会指向错误的位置。因此，存储设计不能只保留start_offset和end_offset，还需要保存用户划选时的文本快照selected_text。这样即使原文变化，阅读器也能通过文本匹配找回大致位置，或者在用户界面上展示当时划中的内容。
除了位置，高亮还带有样式属性，例如黄色、绿色、蓝色，有些应用还支持下划线、波浪线或笔记备注。样式属性相对稳定，但笔记内容会频繁编辑，因此需要把笔记和标注本体放在同一行或关联表中，但要注意更新时不能覆盖掉同步状态。写入频率通常不高，阅读场景中的读操作却多种多样：打开一章要快速取出该章所有标注，切换颜色过滤要按样式筛选，全文搜索要能定位到标注文本或笔记，同步时则要按更新时间找出增量和删除项。这些需求正好对应SQLite的复合索引、FTS5全文索引以及updated_at游标。
表结构设计：用偏移和快照表示一个高亮区间
先看一张核心表的设计。字段不需要过度复杂，但要能支撑后续查询和同步。book_id和chapter_id使用文本或整数都可以，关键是建立联合索引。start_offset与end_offset使用整数，表示相对于章节纯文本的字符偏移。这里要注意，如果阅读器底层是HTML或富文本，偏移计算必须与分词、标签剔除规则保持一致，否则不同客户端得到的区间会不一致。
CREATE TABLE annotations (
id INTEGER PRIMARY KEY AUTOINCREMENT,
book_id TEXT NOT NULL,
chapter_id TEXT NOT NULL,
start_offset INTEGER NOT NULL,
end_offset INTEGER NOT NULL,
selected_text TEXT NOT NULL,
color TEXT NOT NULL DEFAULT 'yellow',
note TEXT,
style TEXT,
version INTEGER NOT NULL DEFAULT 1,
deleted INTEGER NOT NULL DEFAULT 0,
created_at TEXT NOT NULL DEFAULT (datetime('now')),
updated_at TEXT NOT NULL DEFAULT (datetime('now'))
);
CREATE INDEX idx_annotations_chapter ON annotations(chapter_id, deleted, start_offset);
CREATE INDEX idx_annotations_book_update ON annotations(book_id, updated_at);
selected_text保存划选时的原文快照，长度一般不会太大，控制在几KB以内即可。如果用户可能整段整段划选，也可以只存前后边界附近的部分文本，但完整快照对后续搜索和恢复更友好。color和style可以合并成一个字段，但分开更灵活。例如颜色用来做视觉区分，样式用来描述下划线、高亮、波浪线等渲染方式。
deleted字段采用软删除，而不是物理删除。这样同步端可以通过deleted = 1知道需要删除远程对应的标注，避免直接删除造成同步信息丢失。version用于乐观锁，每次编辑时加一。同步服务可以用updated_at作为游标拉取变更，而不用扫描整张表。
查询与合并重叠区间
打开一章时，最常用的查询是按章节取出所有有效标注，并按起点排序。SQL可以写得很直接，复合索引idx_annotations_chapter会命中chapter_id和deleted，避免全表扫描。
SELECT id, start_offset, end_offset, selected_text, color, note FROM annotations WHERE chapter_id = ? AND deleted = 0 ORDER BY start_offset;
颜色过滤同样简单，在WHERE条件中加入color = ?即可。如果颜色值较多，还可以建立chapter_id, color, start_offset的复合索引，减少排序开销。对于几百到几千条标注的章节，这种查询延迟通常可以控制在毫秒级。
另一个常见需求是合并重叠或相邻的高亮区间。用户可能会在同一段文字上反复划选，产生多条起点和终点接近的标注。合并逻辑可以在应用层完成，也可以借助SQL窗口函数先筛选出没有与前一条重叠的记录。下面这个查询使用LAG函数找出每个章节中与前一条结束位置不重叠的起点。
WITH ordered AS (
SELECT id, start_offset, end_offset, color,
LAG(end_offset) OVER (
PARTITION BY chapter_id
ORDER BY start_offset
) AS prev_end
FROM annotations
WHERE chapter_id = ? AND deleted = 0
)
SELECT id, start_offset, end_offset, color
FROM ordered
WHERE prev_end IS NULL OR start_offset >= prev_end;
这个查询只能找出一部分不重叠的起点，完整的区间合并还需要考虑颜色是否相同、是否允许相邻合并等因素。实际应用里，可以先从SQLite取出排序后的所有标注，再在Python或JavaScript里做一次线性扫描合并，逻辑更直观，也便于处理颜色不同的情况。
FTS5全文检索标注与笔记
阅读笔记的价值不仅在于回看某一条标注，还在于从整本书的标注和笔记中搜索关键词。SQLite内置的FTS5模块可以给selected_text和note建立全文索引，查询性能远高于LIKE '%关键词%'。FTS5虚拟表可以使用外部内容表，避免在虚拟表和普通表之间维护两份数据。
CREATE VIRTUAL TABLE annotations_fts USING fts5(
selected_text,
note,
content=annotations,
content_rowid=id
);
CREATE TRIGGER annotations_ai AFTER INSERT ON annotations BEGIN
INSERT INTO annotations_fts(rowid, selected_text, note)
VALUES (new.id, new.selected_text, new.note);
END;
CREATE TRIGGER annotations_ad AFTER DELETE ON annotations BEGIN
INSERT INTO annotations_fts(annotations_fts, rowid, selected_text, note)
VALUES('delete', old.id, old.selected_text, old.note);
END;
CREATE TRIGGER annotations_au AFTER UPDATE ON annotations BEGIN
INSERT INTO annotations_fts(annotations_fts, rowid, selected_text, note)
VALUES('delete', old.id, old.selected_text, old.note);
INSERT INTO annotations_fts(rowid, selected_text, note)
VALUES (new.id, new.selected_text, new.note);
END;
触发器会在标注新增、删除和更新时自动同步FTS索引。删除操作使用的是FTS5的特殊delete命令，需要把虚拟表名作为第一个参数传入，这是很多开发者第一次接入时容易写错的地方。更新操作相当于先删除旧索引记录，再插入新记录。
查询时可以用MATCH语句，比如SELECT ... FROM annotations_fts WHERE annotations_fts MATCH '数据库' ORDER BY rank。中文场景下，FTS5默认按整段文本切分，如果需要对中文按词检索，可以引入tokenize器或配合外部分词扩展。更简单的做法是接受按字匹配的局限，标注文本通常较短，直接搜索关键词效果也不会太差。
增量同步与冲突处理
本地阅读器通常需要与云端或多设备同步标注。SQLite的updated_at字段可以作为同步游标，客户端每次同步时记住上一次成功同步的时间点，然后只查询updated_at大于该时间点的记录，包括软删除记录。这样可以避免每次全量拉取。
SELECT id, book_id, chapter_id, start_offset, end_offset,
selected_text, color, note, version, deleted, updated_at
FROM annotations
WHERE updated_at > ?
ORDER BY updated_at;
游标时间有精度问题，如果同一毫秒内发生多次修改，可能会漏掉部分记录。更稳妥的做法是使用自增的id作为游标，或者结合updated_at与id联合判断。同步服务端则可以维护一个全局版本号，每次变更递增，客户端根据版本号拉取增量。
冲突处理主要发生在同一本书上，两个设备都修改了同一条标注。可以把version字段作为乐观锁，提交更新时要求version与远程一致，如果不一致则进入冲突解决流程。对于高亮标注来说，冲突解决策略可以简单取updated_at较新的一方，或者合并两者的样式和笔记。区间位置冲突比较难自动处理，通常需要用户手动确认保留哪一条。
SQLite本身不支持多客户端并发写，但阅读笔记的写入频率低，单写者模型完全可以接受。把SQLite嵌入到阅读器里，配合FTS5、软删除和增量同步，就可以在不引入额外数据库服务的前提下，把高亮标注的读写体验做到流畅且可维护。