核心区别在于是否考虑词距和文档结构：ts_rank仅基于词频、位置、权重，而ts_rank_cd额外引入词间距离，尤其提升短语匹配精度。
ts_rank 和 ts_rank_cd 的核心区别在哪？
根本不在“谁更准”，而在“要不要考虑词距和文档结构”。ts_rank 只看词频、位置、权重，是经典统计模型；ts_rank_cd 多了一个关键维度：**词与词之间的距离（distance）**，尤其适合短语匹配或强调相邻性（比如搜“人工智能工程师”，两个词挨得越近，得分越高）。
常见错误现象：ts_rank 对“AI 工程师”和“AI 是一种技术，工程师很厉害”打分可能差不多；而 ts_rank_cd 会明显压低后者的分数——因为它把“AI”和“工程师”中间隔了太多词，调和平均距离拉高了。
-
ts_rank适合通用关键词检索，响应快，资源开销小 -
ts_rank_cd必须配合@@查询使用，且只支持tsvector @@ tsquery形式（不能用phraseto_tsquery等封装函数间接调用） - 两者都不自动归一化到 [0,1]；若需标准可比值，必须手动除以排名本身+1，即用标志位
32（rank/(rank+1)）
标准化参数（flags）怎么选？为什么 32 是最稳妥的
postgresql 的 ts_rank 和 ts_rank_cd 都支持 flags 参数控制归一化方式，但很多人直接忽略它，结果发现排序值动辄几百上千，没法跨查询比较。
真正有用的只有几个：
-
32：rank/(rank+1)，强制输出范围在[0,1)，对任意规模数据都稳定，推荐默认加 -
1：除以文档长度的对数+1，适合长文档主导的场景，但短文本会放大噪声 -
8：除以“单独词数量”，对稀疏词向量敏感，容易让含大量停用词的文档失真 - 别混用多个 flags——比如
1|8不是“先除长度再除词数”，而是按顺序依次转换，实际效果难预测
示例：ts_rank_cd(vec, query, 32) 比 ts_rank_cd(vec, query) 更适合做 ORDER BY，尤其当你要把不同字段（标题/正文）、不同表的结果混排时。
中文搜索下，ts_rank_cd 的实际价值被严重低估
中文没有空格分词，靠 jieba 或 zhparser 产出的 tsvector 中，词位（position）往往密集且连续。这时候 ts_rank_cd 的“词距惩罚”机制反而更有效——它能识别出“深度学习模型”是完整短语（位置 5,6,7），而不是三个孤立词。
但要注意一个硬限制：ts_rank_cd 的距离计算只在同一个 tsvector 内部生效，它不理解跨字段关联。所以如果你把标题和正文分别转成 tsvector 再拼接（||），词距会被重置，ts_rank_cd 就退化为 ts_rank。
- 正确做法：用
setweight(..., 'A')给标题加权，再整体转tsvector，确保所有词位在统一坐标系里 - 错误做法：先
to_tsvector(title) || to_tsvector(body)，再喂给ts_rank_cd—— 距离信息已丢失 - 性能影响：
ts_rank_cd比ts_rank多一次距离扫描，QPS 下降约 10%~15%，但对多数中小规模应用可接受
别跳过 gin 索引，否则 ts_rank_cd 再准也白搭
ts_rank_cd 的计算本身不依赖索引，但它前面的 @@ 匹配如果没有索引支撑，就会全表扫描——这时你花时间调参、归一化，结果 90% 时间耗在找匹配行上。
必须建 GIN 索引，且类型要匹配：
- 对纯
tsvector字段：CREATE INDEX idx_gin ON tbl using GIN (tsv_col) - 如果用了自定义分词器（如
zhparser），索引必须显式指定：CREATE INDEX idx_gin_zh ON tbl USING GIN (tsv_col gin_trgm_ops)（注意不是gin_ts_vector_ops） - 没建索引时执行
EXPLAIN ANALYZE select * FROM tbl WHERE tsv_col @@ 'xxx'，你会看到Seq Scan—— 这就是瓶颈所在
复杂点在于：中文分词器输出的 tsvector 通常带位置和权重，GIN 索引必须能解析这些结构。漏掉这步，ts_rank_cd 就只是个好看但跑不起来的装饰函数。