一、共存有三种做法，代价各不相同

1. 全局只装一套，靠切换生效路径

做法是把不同版本装进不同目录，用指向关系或环境变量控制当前哪一个生效。它省空间、切换快，日常用起来顺手。局限也明显：一份全局设定只允许一个默认值，多人共用同一台机器时会互相打乱，甲切到新版本，乙的长任务就在旧版本下失败。

判断办法很直接：只有你能登录这台机器，可以用；有别人也在用，就不要用。共享集群尤其如此，一次误切可能让别人的计算白跑。

2. 在个人目录里各建一棵依赖树

做法是按课题在个人空间里建立独立依赖树，彼此不掺和。它不动全局设定，上手快，适合个人调试与短期试验。代价有两条：一是磁盘占用随课题数量成倍增长，几轮下来自己都记不清哪棵对应哪个项目；二是它多半只隔离到语言层，系统级库的冲突照样存在。

3. 把整份环境封装成一个单元

做法是把某一版本连同系统组件、依赖库、配置文件一起封装，运行时与宿主环境不接触。隔离彻底，也便于随论文一并提交，别人拿到就能重跑。代价是体积偏大、图形界面类工具支持有限，而且这个单元本身仍依赖基础层，基础层一变它也可能起不来。

三种做法并不互斥。常见组合是：共享集群上用封装单元托管老课题，个人工作站用依赖树做日常调试，全局只留一个默认版本供公共工具调用。分工清楚，三套办法各安其位。

二、冲突真正出在三类层面

1. 依赖库层面

同一个库的两个不兼容版本，装上一个就会破坏另一个的调用。这类冲突好发现，程序会直接启动失败或报缺失组件。麻烦的是传递关系：一个库依赖另一个库，一层层往下，末了冲突落在哪个组件身上，往往要顺着依赖关系图往上追。

排查这类问题时，先看报错指向的组件，再看它依赖了谁，别一上手就卸重装。卸重装会顺带把别人的环境改掉。

2. 接口与文件格式层面

接口变了，旧调用参数不被识别，或者默认值被改掉；格式变了，新版本默认写出的文件，旧版本打不开。这一类比依赖冲突更难查，因为程序能启动、也能跑完，只是读到的内容不对或少了字段。

要特别注意读写方向。新版本能读旧格式，不代表旧版本能读新格式——这是单向兼容，做混合环境时很容易栽在这里。

3. 算法行为层面

这一层隐蔽。算法做过调整，同一个输入得到的数值在末尾几位上有差异，或者同一批结果被拆成不同数量的分组。这类改动在发布说明里往往只有一句话，位置还不显眼。

它不报错、不崩溃，只有把结果并排比对时才暴露。若正好在做需要精确复现的比对分析，这种偏差足以让结论走样。

三类层面各对应一种验法：能不能启动、能不能读对、算出来是否一致。三项都做才算验过，只做一项等于没验。

三、向下兼容按文档确认四个点

1. 弃用清单与移除时间

发布说明里通常有一节写「已弃用」，逐条列出将被移除的参数、接口、写法，并给出移除的版本号。这一节要拿自己的流程逐条对照，凡是用到的，当期就改，别等真被移除时被动应对。

判据很干脆：清单上出现过的项，不能算兼容。

2. 文件格式的读写方向

文档常写「支持读取某格式某版本」，要分清是只读、只写还是双向。含糊的地方做一次实测省事：用新版本写一份，再用旧版本读一遍，看是否报错、是否丢字段、单位是否被改写。实测结论写进课题档案，比记在脑子里可靠。

3. 接口与默认参数

同一接口在不同版本里的默认值可能改过。默认值变化不报错，只让结果悄悄跟着变。做法是把文档里的参数表与自己流程中写死的值逐个对照，有差异就显式写出来，不靠默认值兜底。

4. 结果口径与数值精度

文档若提到算法修正、单位调整、精度变化，就要补一条对应的验证用例。办法不复杂：拿一份有已知答案的小数据集，在两个版本里各跑一遍，比较差异是否在可接受范围内。超出范围，说明这条链路不适合混用版本。

四项确认完，出一张结论表：哪些功能双向兼容、哪些单向、哪些不兼容。这张表是后面所有约定的依据，也是新人接手时该先看的一页。

四、把共存落成四条约定

1. 课题根目录放一份版本声明

写明所需版本、关键依赖以及不可替换的组件，版本号精确到末位。运行前先读这份声明再切换，防止凭记忆操作。声明与结果一起归档，多年后复核时，它是能还原当时条件的凭据。

声明不必长，一段就够，但要写清哪些组件不能动、为什么不能动。

2. 按课题分环境，不按人分

按人分容易出现一个人手上三四套环境互相污染的情况，自己也说不清哪次用的是哪套。按课题分，一个课题一套，谁参与谁用同一套，结果才可比。人员流动时环境跟着课题走，不跟着人走。

3. 新版本先并行跑一段

新版本上线不要立刻停掉旧版本。用同一批数据在两个版本里各跑一遍，比对结果，确认差异来源可以解释之后再切。并行期长度按任务周期定，走完一轮完整流程为宜，结束条件提前写清，不靠感觉判断。

4. 不在同一份数据上混跑

同一个数据集，一部分用旧版本处理、一部分用新版本处理，末了合并分析。这种混跑产生的偏差很难发现，因为每一步单独看都正常。要么整批用一个版本，要么分两批各自跑完再比对。

五、切换与回退的阶梯

1. 三级切换粒度

第一级是单次运行切换，本次任务用哪个版本由启动参数决定，跑完即失效，影响面有限。第二级是课题级切换，整个课题锁定一个版本，中途不改。第三级是默认级切换，改变公共环境的指向，影响所有未声明版本的调用。

粒度从小到大，影响面依次扩大。默认级切换要谨慎：改之前通知，改之后验证，并留下记录。

2. 回退要能在分钟级完成

升级敢不敢做，取决于能不能快速退回去。可行做法是保留上一版环境不删，切换靠配置完成，而不是把旧版本卸掉再装回。卸掉再装回动辄半天，期间还会把别人的任务一起打断。

回退动作要提前演练一次。演练过和没演练过，真出事时的差别很大。

3. 先在小范围试

有多个节点或多个成员时，先在一两个节点上切，跑一两个真实任务，观察稳定性再铺开。切换记录写清四件事：哪台、什么时候、从哪个版本到哪个版本、谁操作的。

六、版本台账怎么维护

1. 三态标注

每个版本标一个状态：在用、待退、已归档。在用的保持可用并跟踪文档更新；待退的停止新增使用，只保障已有课题跑完；已归档的转只读，不再进入日常可选集合，但保留重建能力。

不标状态，版本会越堆越多，末了没人敢删，也没人知道哪个还能用。

2. 指定负责人

每个版本有一个负责人，升级与下线的决定由他确认。责任清楚，出现结果偏差时能快速定位到是谁改了什么，外部复核时也有据可查。

3. 定期唤醒检验

封存的环境隔一段时间拿出来跑一遍，确认还能启动。基础层更新、依赖源变更、校验文件过期，都会让封存单元在无人知晓的情况下失效。检验不必频繁，一学期一次足够，但要做，且要留记录。

结语

新旧版本能共存，前提是把冲突分清、把兼容范围查实、把约定写下来。隔离手段本身已经够用，真正容易出错的是判断：以为新版本兼容旧写法，其实只兼容一半；以为结果没变，其实末尾几位已经偏了。文档是这些判断的根据地，但要按章节读，不能只看开头的概述。

落地顺序建议这样：先做一次共存可行性验证，把三类层面的检查跑一遍；再把版本声明与切换粒度的约定写进课题规范；末了建立台账，把在用、待退、已归档分清楚。做完这三步，再有人问「这两个版本能不能一起用」，答案是查表，而不是凭印象。