nlargest 在 groupby.apply 中易出错：组行数不足时返回空导致拼接失败，重复值不指定 keep 会结果不稳定；应显式设 keep、用 group_keys=false、确保数值列，或改用 sort_values+head 更可靠。
nlargest 在 groupby.apply 里为什么只返回空或报错
直接写 df.groupby('col').apply(lambda x: x.nlargest(3)) 很容易出问题：如果某组行数少于 N，nlargest 默认返回空 DataFrame，导致各组结果长度不一致，pandas 自动拼接时会触发 ValueError: cannot concatenate a non-NDFrame object；更隐蔽的是，若没指定 keep 参数且有重复值，排序不稳定，Top N 可能随机波动。
实操建议：
- 必须显式传
keep='all'或keep='first'，避免因重复值导致结果不可复现 - 用
df.groupby('col', group_keys=False)包裹，防止 apply 后多出一层索引干扰拼接 - 对每组单独调用前，先确认目标列是数值型——
nlargest对非数值列（如字符串）直接抛TypeError: 'str' object is not callable
替代方案：用 head() + sort_values() 更稳
当 nlargest 行为不可控时，手动排序取头更透明。它不依赖内部优化逻辑，兼容所有 pandas 版本，且能清晰控制升/降序、缺失值处理。
实操建议：
- 写成
df.groupby('col').apply(lambda x: x.sort_values('score', ascending=False).head(3)) - 加
na_position='last'避免NaN被当成最大值顶到前面 - 如果原始索引要保留，加
reset_index(drop=True)在 head 后，否则 groupby 会把原索引带进来造成混乱
性能差异：nlargest vs sort_values + head
nlargest 底层用的是部分排序（类似堆），理论时间复杂度 O(n log k)，k 是 Top N；而 sort_values 是全排序 O(n log n)。但实际中，当 N 很小（比如 ≤ 10）、组内数据量不大（≤ 1000 行）时，两者差异几乎感知不到；反而 sort_values 因 JIT 编译和 C 实现，在小数据上更快。
实操建议：
- 别盲目迷信
nlargest性能优势——只有单组超万行且 N - 用
df.groupby('col').apply(..., engine='cython')无效，pandas 的 apply 不走 cython 引擎，别白配 - 真要极致性能，改用
pd.concat([g.nlargest(3) for _, g in df.groupby('col')])，绕过 apply 的开销，但得自己处理空组
空组或不满 N 行的处理逻辑
默认情况下，nlargest(3) 遇到只有 2 行的组，就只返回 2 行；而 head(3) 也一样。但如果你需要“强制补满 3 行（用 NaN 填）”，两者都不支持，必须手动 pad。
实操建议：
- 检测空组：在 lambda 里加
if len(x) == 0: return pd.DataFrame(columns=x.columns) - 补行：用
pd.concat([x.nlargest(3), pd.DataFrame([{c: pd.NA for c in x.columns} for _ in range(max(0, 3-len(x)))])])，但注意类型推断可能变object - 更稳妥的做法是先用
size()过滤掉小于 N 的组：df.groupby('col').filter(lambda x: len(x) >= 3).groupby('col').apply(...)
nlargest、多级索引下未重置索引、目标列为 category 类型——会触发静默截断或 dtype 降级，这些地方没报错但结果不对，得盯住输出 shape 和 dtypes。
