数据结构基准要可复现，先把变化因素关起来
性能测试最容易给人一种确定感：终端上多了几行数字，于是某个实现就“更快”。实际上，数据结构基准受编译器版本、CPU 调度、输入分布、垃圾回收和后台负载影响很大。一次结果只能说明当时的运行条件，不足以支持宽泛结论。
可复现不意味着每台机器必须得到完全相同的纳秒数。更现实的目标是，让另一位开发者拿到同一份代码、同一套输入和清楚命令后，能验证功能正确，看到相近的趋势，并知道差异可能来自哪里。
先固定真正影响结果的输入
基准里的数据生成不应隐藏在随机默认值中。元素数量、键的分布、命中与未命中的比例、读写比例、并发度和随机种子，都应明确写在代码或配置中。否则一次测试使用均匀随机键，另一次使用高度重复的键，比较的可能根本不是同一个问题。
还需要定义预期行为。比如查找基准是否包含不存在的键，删除后查询应该返回什么，扩容是否算进测量范围。性能测得再漂亮，如果不同实现遵守的语义不一样，结果没有可比性。先用普通测试守住正确性，再运行基准，避免优化了错误路径。
数据规模也不要只测一个点。很小的数据可能完全落在缓存中，很大的数据又会暴露内存分配和 GC 行为。选择几个能代表实际使用的规模，并说明它们对应的业务假设，比只挑一个对自己有利的样本更有价值。
记录环境，但别把容器当成魔法
每次运行应留下 Go 版本、操作系统、架构、CPU 信息、提交版本、执行命令和是否有资源限制。原始输出比截图更适合保存和比较。若结果异常，记录能帮助排除“换了编译器”或“测试时机器正在构建其他项目”这类干扰。
容器可以锁定依赖与工具版本，却无法消除宿主机的资源竞争和调度差异。使用容器时应说明镜像版本、CPU 和内存限制、是否共享宿主机缓存。不能因为程序跑在 Docker 里，就断言两次性能数据天然可比。
基准开始前是否需要预热、是否要关闭某些后台服务、是否使用固定的 CPU 绑核策略，也取决于团队对精度的需要。最重要的是把采用的条件写下来，而不是假装环境从来不会变化。
每次只验证一个假设
比较哈希策略时，不要同时换数据生成器、改内存分配、升级 Go 版本又调整并发模型。变化因素太多，即使结果改善，也无法归因。一次提交只围绕一个假设：例如新的桶布局是否降低指定分布下的查找成本。其他条件保持不变，才能知道这个改动是否值得保留。
运行也要多次。单次异常可能来自 GC、CPU 抢占或临时缓存状态。查看多次结果的离散程度，必要时用工具做统计比较；若波动很大，先解释为什么波动，再谈谁更快。不要只挑最快的一次放进报告。
分配次数和内存用量同样值得观察。有的实现用更少时间换来大量内存，或在特定规模下产生频繁 GC。性能取舍必须放在资源边界里讨论，而不是只比较一个时间字段。
验收看趋势，也看文档能否重跑
提交基准改动时，提供从干净目录开始的运行说明：如何准备依赖、使用哪个命令、结果写到哪里、如何生成或下载测试数据。让另一台机器或另一位开发者按说明走一遍，确认结果至少在功能和趋势上可以解释。
若不同机器给出相反结论，不要急着宣布谁的环境不对。检查输入、CPU 架构、编译器、内存压力和实现的缓存敏感性，差异本身可能暴露了算法只在特定条件下占优。
好的基准报告会说明测了什么、没有测什么，以及结果适用的范围。这样数据结构试验才能为选型提供证据，而不是留下一个无法复查的终端数字。
