重复索引会导致groupby、loc、reindex、join等操作结果不可控：loc可能返回多行，reindex静默填NaN，join引发笛卡尔积；根本原因是pandas默认索引唯一。
重复索引会导致哪些操作出错
当你对 DataFrame 执行 groupby、loc、reindex 或合并操作时，如果索引含重复值，loc 可能返回多行却只匹配一个标签，reindex 会静默填充 NaN 而不报错，join 则可能产生笛卡尔积——这些都不是你想要的“一对一”行为。
根本问题在于：Pandas 的很多底层逻辑（比如标签对齐）默认假设索引是唯一的。不是“不能运行”，而是“结果不可控”。
reset_index 为什么常被误用
reset_index 本身不解决重复索引的语义问题，它只是把原索引变成一列、再生成新索引（0, 1, 2…）。但很多人以为只要调用一次就“修好了”，其实只是掩盖了问题：
- 原重复索引仍保留在新列里（如
index列），没被清理或标记 - 如果后续又做
set_index('some_col')，而该列本身有重复值，索引立刻再次重复 -
reset_index(drop=True)看似干净，但丢失了原始索引的业务含义（比如时间戳、ID），可能影响后续分析
重置前必须先检查和决策
别急着调 reset_index，先弄清重复是怎么来的、是否合理：
立即学习“Python免费学习笔记（深入）”；
- 如果是读取 CSV 时未指定
index_col，导致行号被当数据读入 → 用pd.read_csv(..., index_col=0)重建索引 - 如果是
concat([df1, df2], ignore_index=False)拼接造成 → 改用ignore_index=True或手动重编号 - 如果是业务上确实存在合法重复（如同一用户多条订单记录）→ 不该强行去重，而应保留原索引，改用
groupby或loc配合布尔索引访问 - 确认要丢弃原索引语义后，再执行：
df = df.reset_index(drop=True)
reset_index 后还要注意什么
重置完只是有了唯一整数索引，不代表数据就“安全”了。容易忽略的点：
- 如果原索引是
DatetimeIndex，reset_index会把它转成普通列，时序属性丢失 → 需手动df['index'] = pd.to_datetime(df['index'])再设回 - 若之后要用
set_index，确保目标列无缺失、无重复；可用df['col'].is_unique快速验证 -
reset_index默认不修改原 DataFrame，记得赋值或加inplace=True（但后者已不推荐） - 在 pipeline 中多次 reset，容易让索引变成“Unnamed: 0”或“level_0”等混乱名称，建议显式命名：
df.reset_index().rename(columns={'index': 'orig_id'})
df.index.is_unique 和 df.index.duplicated().sum()。 
