rank(method='average')常致下游出错，因返回浮点数秩（如[5,5,5]→[2.0,2.0,2.0]），破坏整数位置计数逻辑，影响分位数切分或top N筛选的人数准确性。
pd.Series.rank() 的 method 参数到底选哪个
平局时怎么排，取决于你后续要算什么。不是“哪个更标准”，而是“哪个不破坏你的业务逻辑”。method 本质是定义相同值内部的相对顺序，不影响不同值之间的大小关系。
常见错误是默认用 'average'（默认值），结果下游做分位数切分或 top N 筛选时，发现人数对不上——因为平均秩把整数位置“摊薄”了，rank() 返回的是浮点数，而你可能需要明确的、可计数的整数位置。
-
'min'：并列者取最小秩（如 [1,2,2,4] → [1,2,2,4]）。适合“只要进前 N 就算达标”的场景，比如考试按名次发奖，两个第二名就都没第三名 -
'max'：并列者取最大秩（如 [1,2,2,4] → [1,3,3,4]）。适合“卡分数线”，比如只招前 3 名，那两个第二名占掉第2和第3，第4名就落选 -
'first'：按原始顺序给唯一秩（如 [2,2,1] → [2,3,1]）。适合保留输入顺序语义，比如日志时间戳相同，先到的排前面 -
'dense'：并列者同秩，后续秩紧接（如 [1,2,2,4] → [1,2,2,3]）。适合做梯队划分，“第一梯队”“第二梯队”，不跳空档
为什么 rank(method='average') 常导致下游出错
它返回浮点数秩，比如 [5,5,5] → [2.0,2.0,2.0]，看着没问题，但一旦你写 df[df['score_rank'] ，逻辑是对的；可如果接着做 <code>groupby('score_rank').size()，就会发现秩为 2.0 的组里有 3 行，但你想按“前 3 名”筛选时，根本没法用 2.0 当整数索引去查名次列表。
性能上没差异，但兼容性差：很多依赖整数秩的库（如 scipy.stats.rankdata 的某些 mode）、前端表格排序、SQL RANK() 函数映射，都默认期望整数输出。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 别在需要做
nlargest(n)或切片索引前用'average' - 导出到 Excel 或对接 BI 工具时，浮点秩容易被自动转成字符串或四舍五入，造成歧义
- 如果原始数据有
NaN，记得配na_option='keep'，否则NaN会被排到最前/最后，干扰平局判断
和 SQL 的 RANK()、DENSE_RANK() 怎么对齐
Pandas 的 rank(method='min') 对应 SQL 的 RANK()，rank(method='dense') 对应 DENSE_RANK()。但注意：SQL 默认不处理 NULL 排序方向，而 Pandas 的 na_option 必须显式设，否则行为不一致。
真实迁移案例中，最容易翻车的是 order by 多列后加 rank：SQL 写 ORDER BY dept, salary DESC 再 RANK()，Pandas 得先 sort_values(['dept', 'salary'], ascending=[True, False])，再调 rank(method='min')，顺序错一丁点，平局分组就全乱。
- SQL
ROW_NUMBER()没有直接对应，得用rank(method='first')+ 保证输入已排序 - 别依赖
rank()的索引顺序——它只看值，不看原 index，想保留原始行号得先reset_index() - 大数据量时，
method='first'比其他略慢，因为它要维护原始位置信息
实际用的时候，先问自己这三句话
不翻文档、不试错，三句话决定 method：
- “并列的人，我是否允许后面的人‘跳号’？” → 允许就用
'min'，不允许就用'dense' - “我要拿这个秩去做整数索引或分组计数吗？” → 是，避开
'average'；否，且要保留原始录入顺序，选'first' - “下游系统（SQL / BI / 同事代码）怎么理解这个秩？” → 查对方文档，优先对齐，而不是追求“数学上最合理”
平局本身没标准解，只有上下文里的合适解。多数业务场景真正卡住的，不是 method 选错，而是忘了 ascending 和 na_option 这俩开关——它们不动声色地改写整个排名结构。
