如何在电子日记中排查中英混排环境下的单字搜索问题

从查阅应用自身的搜索文档入手

搜索是应用的特定功能，并不存在通用的普适规则。日记应用可能会使用全文索引、基础文本扫描，或者提供多种检索模式。即便同样基于 SQLite 构建的产品，在所使用的 SQLite 扩展、分词器（tokenizer）以及应用专有逻辑上也会有所不同。例如，[Joplin 的官方文档中说明其使用的是 SQLite FTS4](https://joplinapp.org/help/apps/search/)，并指出对于不使用拉丁词边界的语言（包括中文），应用会切换至自定义模式。其文档还对记录的 FTS 模式下的精确词项匹配与子字符串匹配进行了区分。这些细节仅代表 Joplin 自身的设计，并不能推断其他日记应用也会以同样的方式运行。

请先确认所用产品的具体型号和平台版本，然后查看使用手册中是否说明了全文搜索、基础模式、分词/词项匹配、子字符串匹配、特定语言的行为以及是否对附件等内容建立索引。切勿仅仅因为搜索框支持输入中文，就推断它一定会逐字扫描所有可见字符。反之，也不要预先假设索引会直接忽略中文文本：应用可能内置了针对特定语言的处理模式或其他底层实现。

建立一条轻量的对照笔记

使用一条已知内容的笔记作为受控排查的基准。例如，可以创建一条正文内容为“山水 — 北京 — journal”的虚拟笔记。在这里，“山”是已知的单字测试项；“北京”是已知的双字词；“journal”则是英文对照词。保存该笔记，等待文档中说明的索引延迟时间，然后分别对这三项进行搜索。记录“山”、“北京”和“journal”是否能够分别搜出这条笔记。这些均为建议的验证排查步骤，并非对特定真实应用的测试结论。

如果连“journal”都搜不到该笔记，首先应检查笔记是否已成功保存、是否包含在所选账户或笔记本内，以及是否位于当前的搜索字段范围内。如果“journal”可以正常搜出，但两项中文检索词均无法搜出，则问题通常与 CJK（中日韩）文本处理或搜索词解析方式直接相关。如果“北京”可以正常搜出，而“山”搜不出，请记录下这一差异：这可能指向最短词项限制或分词边界机制，但单凭该结果尚无法直接断定具体底层原因。

仔细区分全文搜索、基础搜索与子字符串搜索

在全文搜索中，应用通常会将文本切分为词项，并针对这些已索引的词项进行匹配。而子字符串搜索则是在长文本中逐个查找字符序列。这是两种截然不同的机制：能够匹配完整词项，并不意味着一定能匹配其中包含的更短子序列。Joplin 在其文档中明确阐述了其 FTS 查询的这一区别，并指出其 CJK 自定义模式避免了对拉丁词边界的依赖。根据其文档，使用斜杠（/）前缀可以切换至基础搜索，以应对 FTS 表现不佳的情况，但 Joplin 同时也提醒该模式的运行速度可能会明显变慢。请仅在 Joplin 中严格按照其最新手册说明使用此类语法，切勿直接套用至其他应用。

数据库官方文档可以解释为何底层实现细节至关重要，但它并不能直接预判具体应用的上层表现。例如，SQLite 的 [FTS5 官方文档](https://sqlite.org/fts5.html)介绍了包括 Unicode61 和 trigram 在内的可配置分词器。然而前文提及的 Joplin 官方文档指明其使用的是 FTS4。因此，不能拿 FTS5 的示例来推断 Joplin 或其他日记应用必定采用了这些分词器。在借助数据库层面的原理进行推测之前，务必优先以应用自身的官方文档为准。

聚焦异常规律，而非单一失败记录

建议按照以下步骤逐步排查缩小问题范围：

切勿将一款应用的搜索语法规则或排查结论直接套用到另一款应用上。例如，Apple 的 [“备忘录”使用手册](https://support.apple.com/guide/notes/search-your-notes-not18ab658ed/mac)介绍了对备忘录正文以及多种附件类型的搜索支持，并指出具体可用功能可能会因账户类型而异。但该手册并未具体说明中文分词边界机制，也没有保证支持单字子字符串检索。当官方文档未就某一点明确表述时，客观合理的结论仅仅是：官方在此处并未公布该行为的具体机制。

对照测试能告诉我们什么

建立对照笔记有助于将“笔记丢失或搜索范围有误”与“特定语言检索机制受限”区分开来。但它无法证明应用如何针对每一篇笔记、附件、账户或语种构建索引。建议将具体的应用名称、运行平台、版本号、搜索模式以及上述三次检索的结果统一记录备查；这份简要明确的记录，远比一句笼统的“中文搜索坏了”更具参考价值。如果真实档案库确实对单汉字检索有稳定需求，在重组架构或重新导入笔记之前，务必先用具有代表性的自有笔记确认实际的检索表现。

继续探索这个主题