ts_rank()分数基于词位位置、密度及字段权重（a/b/c/d）综合计算，采用tf-idf变体：词越集中、靠前、所在字段权重越高，得分越高；须显式传入setweight()处理的tsvector，否则默认全按d权重计算。
ts_rank() 返回的分数到底怎么算出来的
它不是简单统计关键词出现次数，而是基于 tsvector 中词位的位置、密度、字段权重（A/B/C/D）综合计算。默认使用「频率-逆文档频率」（TF-IDF）变体：词在文档中越集中、越靠前、所在字段权重越高，得分越高。
常见误区是以为加了 setweight() 就自动影响 ts_rank() —— 实际上必须显式把带权重的 tsvector 传进去，否则所有字段都按默认权重 D 处理。
- 不带权重的写法：
ts_rank(to_tsvector('zhcn', title || ' ' || body), to_tsquery('zhcn', '搜索'))→ title 和 body 全部视为 D 权重 - 带权重的正确写法：
ts_rank(setweight(to_tsvector('zhcn', title), 'A') || setweight(to_tsvector('zhcn', body), 'D'), to_tsquery('zhcn', '搜索')) - 中文场景务必指定配置（如
'zhcn'），否则默认simple配置会把整段当一个词，无法分词
为什么用 ts_rank_cd() 而不是 ts_rank()
ts_rank_cd() 是「cover density」版本，在短文本或关键词密集场景下更合理。比如商品标题“iPhone 15 Pro Max 256G”，ts_rank() 可能因词频高拉低单个词贡献，而 ts_rank_cd() 更看重词是否「覆盖查询意图」，对精确匹配友好。
性能上两者几乎无差别，但语义敏感度不同：
- 用
ts_rank()：适合长文、博客、文档类，强调词频与分布 - 用
ts_rank_cd()：适合标题、标签、SKU 等短字段，强调关键词是否完整出现、位置是否紧凑 - 注意：两个函数都不支持自定义 IDF，若需业务级权重大调整（比如“品牌名”比“参数”高 3 倍），得用
ts_rank()+ 手动乘系数
GIN 索引必须配合表达式索引才能加速排序
只建普通 GIN 索引（CREATE INDEX idx_gin ON tbl USING GIN (to_tsvector('zhcn', body))）能加速 @@ 匹配，但对 ts_rank() 排序无效——因为排序需要实时计算向量和查询的匹配度，索引不存 rank 值。
真正提速的方式是预计算带权重的向量并建表达式索引：
- 先加一列存储加权向量：
ALTER TABLE tbl ADD COLUMN title_body_tsv tsvector - 用触发器或应用层更新：
setweight(to_tsvector('zhcn', title), 'A') || setweight(to_tsvector('zhcn', body), 'D') - 再建索引：
CREATE INDEX idx_tsv_gin ON tbl USING GIN (title_body_tsv) - 查询时直接用：
SELECT *, ts_rank(title_body_tsv, to_tsquery('zhcn', '搜索')) AS rk FROM tbl WHERE title_body_tsv @@ to_tsquery('zhcn', '搜索') ORDER BY rk DESC LIMIT 10
这样既跳过每次解析开销，又让 WHERE 条件走索引，排序也只在命中行内计算。
中文分词后权重设置容易忽略的坑
PostgreSQL 自带的 zhcn 配置其实不带中文分词能力，它只是把空格/标点当分隔符，对连续汉字不做切分。真要支持中文，得用 pg_jieba 或 zhparser 扩展，并在创建索引时绑定对应字典。
一旦用了扩展，setweight() 的作用对象就变成扩展输出的词位，而不是原始字符串。这意味着：
- 如果分词结果是
'苹果':1A '手机':2A '15':3D，那么只给 title 字段设 A 权重，'15'这种数字词仍按 D 算——除非你在分词前做预处理 - 权重字母（A/B/C/D）大小写敏感，
'a'不合法，会静默退化为 D - 多个
setweight()合并时，相同词位的权重取最高者（比如 A 和 B 同时存在，最终按 A 算），不是叠加
最常被跳过的动作：没在 to_tsquery() 里用同个配置，导致查询词没被同样分词，@@ 直接不匹配——查不到数据，自然排不了序。
