【锚点】这一讲只钉一个判断：【开放科学里，’数据+代码’不等于可复现；缺少【环境锁定】的公开分析，只是把复现失败推迟到读者机器上。】

【显式】很多论文给 data + script，但依赖只写 ‘pandas, numpy, matplotlib’。这不是细节：一个脚本若依赖 10 个包，每个包有 2 个候选版本，读者面对的不是 1 个环境，而是粗略 2^10=1024 个潜在环境。没有 lockfile/container，读者不知道作者到底在哪个环境里运行。

【隐式】版本漂移会改变结果，不只是报错。例：pandas 1.3 时代 df.append 可用；pandas 2.0 移除/弃用后，同一脚本直接失败。更隐蔽的是随机数、默认参数、绘图默认样式变化：图看起来差不多，但误差条、坐标、颜色映射可能已变。对【数据可视化】来说，图不是可复现对象；【生成图的代码+环境+随机种子】才是。

【细微】真正可检验的最小单元是：【干净环境】→【锁定依赖】→【固定随机种子/数据版本】→【运行脚本】→【图与统计量一致】。少任何一环，读者只能做近似复现。可用 conda-lock、pip freeze、R 的 renv、Docker/containers 固定环境；requirements.txt 若只有包名，通常只锁了名字，没锁版本/哈希。

【极难发现】更深的盲点：我们常把’代码公开’当作信任，但它只证明作者愿意展示过程，不证明过程可被他人独立执行。开放科学的信任链应该是：【数据】→【代码】→【环境】→【执行日志/输出】→【可拒绝报价】。若某一步出现不同版本、不同随机结果或不同图，结论必须降级，而不是默认作者环境为准。

【待验证点】如果你把一篇论文只给 data+script 视为开放，你默认了读者的环境税由读者承担。问题：你愿意把 lockfile/container 列为开放科学最低门槛，还是认为它只是工程细节？