Pandas按索引排序与恢复原始顺序方法

df.sort_index()无法恢复原始顺序，因为它仅按当前索引值排序，不保存历史顺序；原始顺序需提前保留索引或添加序号列才能可靠还原。

直接说结论：用 df.sort_index() 无法“恢复原始顺序”，因为 Pandas DataFrame 一旦重排索引（比如通过 iloc、sample、concat 等操作），原始顺序就丢失了——除非你提前保留过原始索引或行号。

为什么 sort_index() 不等于“还原初始顺序”

很多人误以为调用 df.sort_index() 就能回到刚读入数据时的样子，其实它只是按当前索引值升序排列。如果原始索引是 [0, 1, 2, 3]，后来你做了 df.iloc[[2, 0, 3, 1]]，新索引还是 [2, 0, 3, 1]，这时 sort_index() 确实会变回 [0, 1, 2, 3]；但如果你执行过 df.reset_index(drop=True) 或 pd.concat(..., ignore_index=True)，索引已变成 [0, 1, 2, 3]，但行内容和原始顺序可能早已错位——此时再 sort_index() 毫无意义。

• 原始顺序信息只存在于“未被覆盖的索引”或“额外保存的列”中
• sort_index() 只排序，不记忆历史
• 如果索引被重置为默认整数且未打乱，看起来像“还原”，其实是巧合

真正能恢复原始顺序的两种可靠做法

前提是：你得有线索。最常用的是在加载/处理初期就埋下标记。

• 读取 CSV 时加 df = pd.read_csv("x.csv", index_col=0) 保留原始 ID 列作索引（前提是该列唯一且有序）
• 处理前手动加一列记录原始位置：df["__orig_order"] = range(len(df))，之后用 df.sort_values("__orig_order").reset_index(drop=True)
• 如果只是想按读入顺序还原，且没动过索引，那原始索引本来就是 range(len(df))，直接 df.reindex(range(len(df))) 更直白（比 sort_index() 少一层语义误解）

sort_index() 的常见误用场景和坑

这几个地方最容易栽跟头：

• 对 reset_index(drop=True) 后的 DataFrame 调用 sort_index() —— 索引是 [0, 1, 2...]，排序后完全没变化，你以为“还原”了，其实早就不对了
• 索引含重复值（比如多个 "A"），sort_index() 会按插入顺序稳定排序，但无法保证和原始物理顺序一致
• 用了 inplace=True 却忘了检查返回值是否为 None，后续链式调用出错
• MultiIndex 场景下，默认只按第一级排序，要完整还原需显式写 df.sort_index(level=[0,1])

性能与兼容性提醒

sort_index() 在大数据量下不是免费操作：它本质是基于索引数组的排序，时间复杂度 O(n log n)，且会触发底层 copy（除非明确用 inplace=True 且满足内存连续等条件）。

• 如果只是想“按原始行号排”，用 df.iloc[np.argsort(df.index)] 通常更快（尤其索引是简单整数时）
• Pandas 2.0+ 对 sort_index() 的 kind 参数更敏感，默认 "quicksort" 不稳定，若需稳定排序（相同索引值保持原相对顺序），得加 kind="mergesort"
• 当索引是 DatetimeIndex 或 CategoricalIndex，行为可能和普通 Int64Index 不同，别假设通用

真正难的从来不是怎么调用 sort_index()，而是你根本不知道“原始顺序”到底指哪一刻的顺序、有没有被悄悄覆盖过。留痕，比补救重要得多。