正确做法是df.groupby('col')['target'].rank(method='min')，必须显式指定method；避免apply(lambda x: x.rank())以防内存爆炸；空值用na_option控制，推荐method='min', na_option='keep'。
用 groupby().rank() 做分组内排名，但必须指定 method
直接调用 df.groupby('col').rank() 会报错或返回意外结果——Pandas 默认不支持对 GroupBy 对象直接调用 rank()。正确做法是先 groupby，再对目标列（如 'score'）调用 rank()，且必须显式传入 method 参数，否则默认行为在分组上下文中不可靠。
常见错误现象：TypeError: rank() missing 1 required positional argument: 'axis' 或排名结果跨组“泄露”（比如组 A 最大值排第 1，组 B 最小值也排第 1，但实际想让每组都从 1 开始独立编号）。
-
method='min'：并列时取最小名次（如两个并列第 1，则下一个为第 3），最常用 -
method='dense'：并列后名次连续（并列第 1，下一个为第 2），适合榜单展示 -
ascending=False要加在rank()内，不是groupby()后
示例：
df['rank_in_group'] = df.groupby('category')['score'].rank(method='min', ascending=False)
内存爆炸？别用 apply(lambda x: x.rank())
面对千万行数据，有人习惯写 df.groupby('key').apply(lambda g: g['value'].rank(...))，这会触发 Python 级循环 + 多次副本，速度慢、内存翻倍。Pandas 的 groupby().rank() 是 C 实现的向量化路径，快一个数量级以上。
立即学习“Python免费学习笔记（深入）”；
性能影响明显：1000 万行 × 100 个分组，apply 方式可能耗时 >30 秒且吃光 16GB 内存；而原生 groupby().rank() 通常在 2–5 秒内完成，内存增长可控。
- 确保目标列已设为数值类型（
pd.to_numeric()），避免隐式转换拖慢 rank - 如果分组键含大量唯一值（如用户 ID），
rank()仍高效；但若分组数超百万，考虑先抽样验证逻辑
处理空值和重复值：na_option 和 method 要配对用
空值默认排在最后（na_option='keep'），但如果你希望空值不参与排名、也不占位（即跳过它们，其余值连续编号），就得设 na_option='drop' —— 注意这会让返回结果长度变短，无法直接赋值回原 DataFrame，必须用 transform。
重复值的处理完全由 method 控制，和是否分组无关，但容易被忽略的是：method='average' 在海量数据中会引入浮点精度误差，且名次非整数，后续做 top-N 截断时需 astype(int) 或四舍五入，反而增加出错概率。
- 推荐组合：
method='min', na_option='keep'（最稳） - 若业务要求空值排最前，用
na_option='top'，但注意这会改变语义（比如“未评分”被当成最高分） - 用
transform而非apply可保持索引对齐：df['rank'] = df.groupby('k')['v'].transform('rank', method='min')
超过内存怎么办？用 chunksize + 分组聚合中间态
当数据大到连 read_csv 都加载不了，就别硬扛单次 groupby().rank()。核心思路是：分块读入 → 每块内按 key 聚合出该块的局部排名信息（如最大值、计数、分位点）→ 合并各块统计量 → 推导全局排名边界 → 再分块打标。
但这太重。更实用的折中法是：用 pd.read_csv(..., chunksize=N) 逐块计算，每块用 transform 打局部 rank，然后把所有块 concat 后，在内存允许范围内做一次最终去重/校准（例如用 value_counts() 校验每组总行数，确认局部 rank 是否覆盖完整）。
- 关键限制：分块不能打断同一分组（比如同一
user_id分散在两块），需预排序或用iterator=True+ 手动缓冲 - 简单场景下，先用
df.sample(frac=0.1)快速验证逻辑，比调试全量 chunk 流程快得多
真正上生产前，务必用真实分布的数据测 groupby().rank() 的内存峰值——有时候不是数据量大，而是分组键的 cardinality（唯一值数量）过高导致哈希表膨胀，这才是隐形瓶颈。
