以前公司里的开发环境，用一个词形容就是——
灾难。
每次有新人进来，光是把本地开发环境搭起来，就得磨洋工半个月。老项目跑在Python 3.6的祖宗版本上，新项目非得是3.10，两边版本一装，必然打架。我的个人机器更是惨不忍睹，为了给几个外包项目救火，我装了四五个版本的Node，三个JDK，还有那该死的VS2015和VS2022的残骸。每次开新活儿，都得屏住呼吸，生怕哪个依赖链条断了，然后浪费一整天去排查PATH路径里的鬼东西。
起步：为什么要搞这个“大兄弟版本大全”？
我为啥对版本管理这么敏感？因为我吃过大亏。前年接了个急活，甲方催得要死，我连轴转熬夜两天终于在我的本地机器上跑通了所有测试。结果第二天，屁颠屁颠地把代码和配置拷过去，在他们的服务器上一跑，直接给我甩脸色，报了一堆莫名其妙的依赖错误。我一看，卧槽，就因为Python小版本差了一级，一个核心模块的API调用方式变了。那次我差点被甲方骂得狗血淋头，差点把饭碗砸了。从那以后，我就发誓，环境版本必须老老实实给我站队，谁也别想搞特殊。
我的初步想法是，能不能用Docker彻底全包了？结果发现，我手头上有些活儿涉及到硬件加速或者特定驱动，Docker搞起来特别麻烦，部署又重又慢。而且每次我要快速切换测试环境，光是等镜像启动和拉取依赖，我的火气就上来了。不行，这效率太低，得找个更直接、更痛快的办法，一个能让我快速在不同“大兄弟”环境里闪转腾挪的办法。
实践过程：从大杂烩到版本军规
我决定彻底整理，把所有常用的环境配置，按它们的性质，分门别类，像给它们建隔离房一样。这个过程的核心就是：用管理器去管理管理器。
我从操作系统层面开始下手，我把所有需要版本隔离的工具，全部用对应的版本管理器接管，并且要求它们不能污染全局环境。这个过程听起来简单，但实施起来是地狱级别的细致活儿，我可是花了一个周末的时间，把所有老版本的垃圾都铲干净了。
我总结了我的“大兄弟版本军规”：
- Node大兄弟：扔掉传统的安装包。直接上NVM（Node Version Manager）。我需要哪个版本，敲个命令，它就给我建一个独立的盒子。不同项目要用不同的npm包？没关系，NVM已经把它们隔得清清楚楚，老死不相往来。
- Python大兄弟：Venv这玩意儿虽然能用，但是换版本太麻烦。我换成了Pyenv。安装过程费了点劲，但一旦装我可以在同一台机器上，跑3.6, 3.8, 3.10，甚至最新的测试版，它们各自活得滋润，互不干扰。
- Java大兄弟：这个最麻烦，JDK版本管理我找了一圈，用的SDKMAN。这玩意儿虽然是给Linux和Mac用的，但我硬是在Windows上折腾出来了。现在我要换JDK 8还是JDK 17，一句话搞定。
- 数据库大兄弟：MySQL和PostgreSQL这种，我干脆放弃本地安装。全部扔进了Docker Compose，用的时候启动，不用的时候关掉，干净利索，连注册表里的垃圾都不用管。
关键操作：脚本化切换。
我把每一个项目的启动脚本都改了。现在项目跑起来之前，脚本要做的第一件事，不是启动代码，而是检查配置——“喂，你这个项目需要的Node是16.x版本吗？好的，NVM，切换！”整个过程自动化，完全屏蔽了人工操作可能带来的版本污染。
结果：实现了真正的心平气和
这套“大兄弟版本大全”搞定之后，我才算是实现了真正的开发自由。以前一开新项目，心头就一紧。管你甲方要什么远古版本，还是想试最新的黑科技，我都游刃有余。
很多人觉得搞这些环境管理工具是浪费时间，不如直接装一个版本用到老。但他们没明白，时间不是浪费在安装上，是浪费在排查那些因为版本依赖冲突而产生的怪异Bug上。
现在我给我的团队也推行了这套东西。以前新同事入职，两个星期在装环境。现在半天。他们不用知道底层是怎么切换的，他们只需要知道，项目A跑在A环境，项目B跑在B环境，互不影响。这才是真正的效率提升，把那些扯皮的时间，全部拿来写代码。
环境搭得稳，人才能稳。这趟版本整理的实践，让我意识到，越是基础的东西，越要花大力气去规范。别把自己的生产力，浪费在跟电脑吵架上面。
这回分享就到这儿，下次再聊聊我怎么用一套脚本管理所有服务的配置，那是另一段血泪史了。