不靠谱。单次测量噪声高，须多轮重复（如timeit.repeat(repeat=5, number=10)）、取中位数、固定随机种子、调用gc.collect()、禁用sort=true，并确保索引状态与依赖版本严格一致。
用timeit测单次merge耗时是否靠谱？
不靠谱。Pandas merge受数据分布、索引状态、内存对齐影响极大，单次测量噪声高，尤其在小数据集上容易得出错误结论。必须做多轮重复 + 统计摘要，且要固定随机种子和GC行为。
- 用
timeit.repeat(repeat=5, number=10)而非timeit.timeit()，取最小值或中位数（推荐中位数） - 每次运行前调用
gc.collect()，避免垃圾回收干扰 - 构造测试数据时用
np.random.default_rng(seed=42)固定生成逻辑，确保不同版本输入完全一致 - 禁用自动排序：传参
sort=False，否则 Pandas 1.5+ 默认排序会引入额外开销，造成版本间不公平比较
哪些参数组合最影响merge性能对比结果？
不是所有 merge 场景都等价。忽略参数差异直接比“谁快”，等于拿不同赛道比百米成绩。关键变量有三个：
-
how类型："inner"通常最快，"outer"最慢；但 Pandas 2.0+ 对"left"做了哈希优化，而 1.5.x 仍走传统路径，差异可能达 3× -
onvsleft_on/right_on：当列名不同时强制指定后者，否则 Pandas 会尝试列名推断（1.5.x 更慢），且推断逻辑在 2.0+ 有变更 - 是否预设索引：
left.set_index("key")后再 merge，在 1.5.x 中几乎无加速，但在 2.0+ 中触发索引哈希路径，提速显著——但前提是索引已排序且唯一
如何隔离Pandas版本环境避免依赖污染？
用 conda 或 venv 分环境是必须的，但光建环境不够。常见陷阱是 pip install 时拉入不兼容的 NumPy 版本，导致底层算法降级（比如 Pandas 2.0 需要 NumPy ≥ 1.24 才启用新字符串处理路径）。
- 用
conda create -n pandas15 python=3.9 pandas=1.5.3 numpy=1.23和conda create -n pandas22 python=3.9 pandas=2.2.2 numpy=1.26显式锁死组合 - 验证关键依赖：进入环境后运行
import pandas as pd; print(pd.__version__, pd._libs.skiplist.__name__)，Pandas 2.0+ 应输出skiplist模块名，1.5.x 是hashtable - 禁止跨环境共享
~/.cache/pip，加--no-cache-dir安装
实际跑出来的性能差距到底看什么指标？
别只盯着平均耗时。merge 性能拐点往往藏在数据规模变化中，线性增长还是指数增长，比绝对数值更重要。
- 至少测三组数据量：1k、10k、100k 行（保持 key 分布一致），画 log-log 图看斜率
- 关注内存峰值：用
memory_profiler的@profile装饰器，Pandas 2.0+ 在某些 outer join 场景下内存占用反而升高 20%，因为改用更通用但更占内存的算法 - 检查 warning：如果 Pandas 2.2 报
UserWarning: merging with duplicate keys而 1.5.3 静默处理，说明底层去重逻辑变了，此时性能对比失去业务意义
真正难的是让两套环境下的 key 分布、缺失值比例、字符串编码完全一致——稍有偏差，merge 就会走不同代码路径，测出来的是 bug 不是性能。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
