groupby后直接sort_values无效，因它作用于全局而非组内；正确做法是先分组再用apply+sort_values或nlargest实现组内topn。
groupby 后用 apply(sort_values) 为什么结果不对？
直接在 groupby 后链式调用 sort_values 会失败，因为 sort_values 是 DataFrame 方法，而 groupby 对象的 apply 传入的是每个分组的子 DataFrame —— 但默认 apply 返回的是 Series 或标量，容易丢失结构。更关键的是：不指定 by 和 ascending 参数，排序逻辑不明确；没重置索引或保留原始行号，取前 N 时可能错位。
正确做法是：在 apply 内部显式调用 sort_values，并用 head(N) 截断，同时设置 reset_index(drop=True) 避免多层索引混乱：
df.groupby('category').apply(lambda x: x.sort_values('score', ascending=False).head(3)).reset_index(drop=True)
想保留原始索引怎么办？
默认 head() 会丢弃原始索引，如果后续要关联原始数据（比如做 join 或 debug），必须显式保留。这时不能依赖 reset_index，而应在排序后用 iloc 或直接切片，并禁用 drop=True：
-
sort_values(...).head(3)自动保留原索引，但需确认分组内索引未被重排过 - 若原始 DataFrame 索引不连续或有重复，建议先用
df.reset_index(name='orig_idx')把索引存为列，再分组操作 - 取完前 N 后用
set_index('orig_idx')恢复，比靠索引位置更可靠
性能差、卡住？试试 nlargest 而不是 sort_values + head
对大数据量分组（尤其 N 远小于组大小时），sort_values 全排序开销大。nlargest 底层用堆，复杂度 O(n log k)，快得多，且语义更清晰：
df.groupby('category')['score'].nlargest(3).reset_index(level=1, drop=True)
注意：nlargest 返回的是 Series，索引是两级（group key + 原始索引），reset_index(level=1, drop=True) 可还原为单级索引并丢掉内部序号；如果还要其他列，得用 join 回原表，或者改用：
df.loc[df.groupby('category')['score'].nlargest(3).index.get_level_values(1)]
遇到 NaN 怎么办？nlargest 默认 skipna=True，但 sort_values 不会自动跳过
nlargest 默认忽略 NaN，而 sort_values(..., na_position='last') 才能控制 NaN 位置。如果业务要求把 NaN 当最低分处理，必须显式设 na_position：
-
sort_values('score', ascending=False, na_position='last')—— NaN 排末尾 -
nlargest(3, keep='all')会把 NaN 当有效值参与比较，导致结果异常；应避免 - 稳妥做法：提前用
fillna(-float('inf'))或dropna()清洗，而不是依赖排序行为
分组内排序取 top N 看似简单，但索引残留、NaN 处理、性能路径选择这三点最容易漏掉——尤其是用 nlargest 时忘记它只返回索引，不带其他列。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
