PostgreSQL中唯一靠谱的内置高亮方案是ts_headline()，它接收原文、ts_query和配置参数，返回带标签的高亮片段，需确保字典与ts_vector构建时一致。
PostgreSQL里用 ts_vector 和 ts_query 做关键词高亮，得自己拼HTML
PostgreSQL原生不提供高亮函数，ts_vector 只负责索引和匹配，ts_query 负责解析查询词——高亮必须靠应用层或自定义函数实现。常见做法是先用 plainto_tsquery() 或 to_tsquery() 构造查询，再用 ts_rank() 排序，最后在程序里拆分原文、逐词匹配并包裹 <mark></mark> 标签。
容易踩的坑：to_tsquery('english', 'run & jump') 会严格要求同时出现且顺序无关，但若用户输的是短语“run jump”，plainto_tsquery() 更贴近直觉；另外，ts_vector 默认用 english 字典，对带标点、大小写、复数的词会做归一化，高亮时若直接拿原始词去替换，可能对不上。
- 先查出匹配的文档和对应
ts_vector：SELECT id, title, content, to_tsvector('english', content) AS tv FROM articles WHERE tv @@ plainto_tsquery('english', 'search term'); - 在应用中（如Python）用
pg_search或手动调ts_headline()更省事——它才是真·高亮函数 - 别对
ts_vector输出直接字符串匹配：它内部是归一化后的词位（lexeme），比如 “running” → “run”，你得用同样字典还原或改用ts_headline()
MySQL用 MATCH ... AGAINST 无法高亮，必须配合SUBSTRING_INDEX或正则
MySQL的全文检索只返回匹配与否和相关性分数，MATCH(title, content) AGAINST('keyword' IN NATURAL LANGUAGE MODE) 不提供位置信息，也没内置高亮函数。想加 <em></em>，只能靠SQL硬凑，或者把高亮逻辑移到应用层。
典型错误是写 REPLACE(content, 'keyword', '<em>keyword</em>')——这会误替所有出现（包括非关键词上下文），且大小写、词边界全不管。更糟的是，MATCH 本身对停用词、最小长度敏感（默认 ft_min_word_len=4），搜“cat”可能根本没结果，你还高亮个空。
- 确保
ft_min_word_len和ft_stopword_file配置与业务一致，改完要重启mysqld并重建FULLTEXT索引 - 用
IN BOOLEAN MODE可支持+/-语法，但依然不返回关键词位置；AGAINST(... IN BOOLEAN MODE)返回值仍是布尔+分数，不是片段 - 真要在SQL里试：可用
REGEXP提取前后各20字符，再用CONCAT()拼<mark></mark>，但性能差、不可靠，仅限调试
ts_headline() 是PostgreSQL唯一靠谱的内置高亮方案
别绕弯子，ts_headline() 就是为这事设计的：输入原文、ts_query、配置参数，它返回已高亮的片段，默认用 <span class="searchmatch"></span> 包裹，还支持截断、省略号、最大长度控制。
关键参数影响大：StartSel 和 StopSel 决定高亮标签，MaxWords/MinWords 控制返回多少词，FragmentDelimiter 是多段匹配时的分隔符。默认返回最多35词、省略前后内容，对长文章很友好。
- 基础用法：
ts_headline('english', content, plainto_tsquery('english', 'postgres sql'), 'StartSel=<mark>, StopSel=</mark>, MaxWords=10, MinWords=5') - 注意字典必须和建
ts_vector时一致，否则词干不匹配，高亮失效 - 若字段含HTML，先用
strip_tags()（应用层）或regexp_replace(content, ']+>', '', 'g')清洗，否则ts_headline()可能错乱
ES或Meilisearch这类引擎高亮更稳，但PG/MySQL原生方案够中小项目用
如果你已经在用PostgreSQL，ts_headline() + GIN索引完全能撑起万级文档的搜索高亮；MySQL则建议只用于简单后台管理搜标题，别对正文高亮抱幻想。上Elasticsearch当然有 highlight API，但引入新服务意味着运维、同步、延迟、一致性问题——很多团队卡在“要不要切ES”上，其实80%场景，ts_headline() 加缓存就足够。
真正容易被忽略的是：高亮依赖查询词和文档预处理的一致性。比如你在 to_tsvector() 里用了 english 字典，那 ts_headline() 和 plainto_tsquery() 就必须用同一个；如果前端传的是“running”，而字典把它转成“run”，你却试图高亮“running”，那就永远套不上。
