PostgreSQL中唯一靠谱的内置高亮方案是ts_headline()
在PostgreSQL里实现全文检索关键词高亮，ts_headline()函数是绕不开的“官方答案”。它接收原文、ts_query查询对象和一系列配置参数，最终返回一个已经包裹好标签的高亮文本片段。这里有个关键细节：构建ts_vector时使用的字典配置，必须与调用ts_headline()时保持一致，否则词干匹配不上，高亮就会失效。
PostgreSQL里用 ts_vector 和 ts_query 做关键词高亮，得自己拼HTML
首先要明确一点：PostgreSQL的原生全文检索功能，其核心是匹配和排序，而非直接呈现。ts_vector负责创建可索引的词位，ts_query负责解析查询条件——至于如何把匹配到的词在原文里标亮，数据库本身并不提供现成函数。因此，常见的做法是先在应用层构造查询（使用plainto_tsquery()或to_tsquery()），再利用ts_rank()进行相关性排序，最后不得不由应用程序接手，手动拆分原文、逐个匹配关键词并包裹HTML标签。
这个过程听起来简单，实则暗藏玄机。举个例子，to_tsquery('english', 'run & jump')会严格查找同时包含“run”和“jump”的文档，且顺序无关；但如果用户输入的是短语“run jump”，使用plainto_tsquery()往往更符合直觉。另一个典型的“坑”在于：ts_vector默认使用english等配置字典，会对原始文本进行归一化处理，比如转换大小写、移除标点、处理复数词干（“running”会变成“run”）。如果你直接拿用户输入的原词去原文里做字符串替换，很可能会因为词形对不上而高亮失败。
- 标准查询流程：先通过类似
SELECT id, title, content, to_tsvector('english', content) AS tv FROM articles WHERE tv @@ plainto_tsquery('english', 'search term');的语句找到匹配的文档及其对应的ts_vector。 - 更优解：与其在应用层重复造轮子，不如直接利用PostgreSQL内置的
ts_headline()函数，或者借助像pg_search这样的成熟库，它们才是真正为高亮场景设计的工具。 - 核心提醒：切勿对
ts_vector的输出结果进行直接的字符串匹配。它内部存储的是归一化后的词位（lexeme），与原始文本已不相同。高亮操作必须基于相同的字典配置来还原，或者干脆交给ts_headline()处理。
MySQL用 MATCH ... AGAINST 无法高亮，必须配合SUBSTRING_INDEX或正则
切换到MySQL的场景，情况并没有变得更容易。MySQL的全文检索函数MATCH ... AGAINST核心价值在于判断匹配和计算相关性分数，它既不提供关键词在原文中的具体位置信息，也没有任何内置的高亮功能。想要实现高亮，只剩下两条路：要么在SQL语句里用SUBSTRING_INDEX、LOCATE或正则表达式硬拼，要么就把高亮逻辑完全放到应用层去处理。
这里有一个非常普遍的误区：试图用REPLACE(content, 'keyword', 'keyword')来解决问题。这种方法极其粗糙，它会替换文中所有出现的字符串，完全不管该词是否真的是本次搜索的关键词，也无法处理大小写和词边界问题。更棘手的是，MySQL全文检索本身对停用词和最小词长有严格限制（例如默认ft_min_word_len=4），搜索“cat”这类短词可能根本不会有结果，高亮也就无从谈起。
- 配置先行：务必确认
ft_min_word_len（最小词长）和ft_stopword_file（停用词表）的配置与你的业务需求匹配。修改后需要重启MySQL服务并重建全文索引。 - 模式局限：即使使用
IN BOOLEAN MODE模式来支持更复杂的查询语法（如+,-），返回的依然是布尔值和分数，而非可以用于高亮的文本片段。 - 权宜之计：如果非要在SQL层尝试，可以结合
REGEXP定位关键词，再用CONCAT拼接前后文和标签。但这种方法性能差、可靠性低，通常只建议在调试或极其简单的场景下使用。
ts_headline() 是PostgreSQL唯一靠谱的内置高亮方案
所以，别再绕远路了。对于PostgreSQL用户来说，ts_headline()就是为此而生的工具。它接收原文、查询对象和配置，直接返回处理好的高亮片段。默认情况下，它会用标签包裹关键词，并且贴心地提供了截断长文本、添加省略号、控制返回片段长度等功能。
这个函数的强大之处在于其丰富的参数，它们直接影响输出效果：StartSel和StopSel决定了高亮标签的样式；MaxWords和MinWords控制返回片段的词汇量；FragmentDelimiter则用于分隔多个匹配的片段。默认设置会返回最多35个词的片段，并自动省略不相关的前后内容，对于处理长篇文章非常友好。
- 基础调用示例：
SELECT ts_headline('english', content, plainto_tsquery('english', 'postgres sql'), 'StartSel=, StopSel=, MaxWords=10, MinWords=5'); - 一致性是关键：再次强调，这里使用的字典（如‘english’）必须与创建
ts_vector索引时所用的字典完全相同，否则词干提取规则不一致，高亮必然失效。 - 处理含HTML的文本：如果待搜索的字段本身包含HTML标签，建议先使用
strip_tags()（在应用层）或regexp_replace(content, '<[^>]+>', '', 'g')（在数据库层）进行清洗。否则，ts_headline()可能会因为标签的干扰而输出混乱的结果。
ES或Meilisearch这类引擎高亮更稳，但PG/MySQL原生方案够中小项目用
当然，如果追求更强大、更专业的高亮功能，Elasticsearch或Meilisearch这类专用搜索引擎是更好的选择。它们提供了成熟的highlight API，支持多种高亮策略和更精细的控制。但是，引入一个新组件意味着额外的运维成本、数据同步延迟以及系统复杂度的提升。
很多团队会陷入“是否要迁移到ES”的纠结中。实际上，对于绝大多数中小型项目而言，这个决定可能为时过早。如果你的技术栈已经基于PostgreSQL，那么利用好ts_headline()函数，再配合GIN索引和适当的查询缓存，完全能够支撑起万级别文档量的搜索和高亮需求。至于MySQL，它的原生全文检索更适合用于后台管理等对高亮要求不高的简单搜索场景，若要对正文进行复杂高亮，或许应该重新评估技术选型。
最后，一个容易被忽略但至关重要的点是：高亮的准确性极度依赖于查询词处理与文档预处理的一致性。整个链路——从构建ts_vector索引，到解析用户查询生成ts_query，再到调用ts_headline()——必须使用完全相同的字典配置。如果前端传入的是“running”，而字典将其归一化为“run”进行索引和查询，那么你试图在原文中高亮“running”这个词的尝试，将永远不会成功。理解并确保这份一致性，是用好数据库原生全文检索高亮功能的前提。
