reset_index 默认将旧索引转为列，列名为原索引名（未命名则为'index'）；加drop=True则丢弃索引不生成列；多级索引时各级均转为独立列；name参数可指定新列名（pandas≥1.5.0，仅单级有效）。

reset_index 为什么没把索引变回列？

常见错误是调用 df.reset_index() 后发现原索引“消失”了，但也没出现在列里——其实是它默认把旧索引作为新列插入，同时生成了从 0 开始的默认整数索引。但如果你的 DataFrame 原本是多级索引、或用了 drop=True，就容易漏掉这列。

关键判断点：检查返回的 DataFrame 是否多了一列叫 index（单级）或对应索引名的列（如 date, category）。

• 默认行为：df.reset_index() → 旧索引变列，列名为原索引名（若未命名则为 'index'）
• 如果加了 drop=True，旧索引直接丢弃，不会变成列
• 多级索引时，每一级都会变成独立列，列名就是各级索引名

如何保留原索引名作为列名

很多人希望索引转成列后，列名不是生硬的 'index'，而是原来设置的索引名（比如 'user_id'）。这取决于你当初是怎么设索引的。

如果原索引有名字：df.index.name = 'user_id'，那 reset_index() 会自动用这个名字当列名；如果没设过名字，就会 fallback 成 'index'。

• 给索引起名再重置：df.index.name = 'timestamp'; df.reset_index()
• 重置后改列名：df.reset_index().rename(columns={'index': 'ts'})
• 一步到位（推荐）：df.reset_index(name='ts') —— 注意这个 name 参数只在 pandas ≥ 1.5.0 支持，且仅对单级索引有效

reset_index 和 set_index 是可逆操作吗？

表面上看是，但实际有陷阱：reset_index 生成的新列默认不设为索引，而 set_index 需要明确指定哪一列来重建。更麻烦的是，如果原索引含重复值或 NaN，set_index 可能报 ValueError: Index has duplicate keys。

• 安全往返的前提：原索引无重复、无缺失、类型兼容（比如时间索引转列后仍是 datetime64）
• 验证是否可逆：df.index.is_unique and df.index.notna().all()
• 避免踩坑：若只是临时需要列数据，优先考虑 df.assign(id=df.index)，不改动索引结构

性能差异：inplace=True 还是赋值？

reset_index(inplace=True) 看似省事，但 pandas 自 2.0 起已标记其为 deprecated，未来会移除。而且它不返回值，容易在链式调用中中断流程。

• 现在推荐写法：df = df.reset_index() —— 显式、可预测、兼容性好
• 内存影响很小：pandas 大部分操作本就是 copy-on-write，inplace 并不真正节省内存
• 唯一例外：超大 DataFrame 且确定后续不再用原索引，可先 del df.index 再 reset，但极少需要

最常被忽略的一点：如果 DataFrame 来自 groupby().apply() 或某些聚合结果，它的索引可能带元数据（如 is_monotonic），直接 reset_index 不会清除这些属性，可能导致下游 merge 或 join 出意外对齐。真要干净还原，得配 df = df.copy() 先断引用。