在心理测评 SaaS 的发展初期，研发团队往往沉浸在“所有客户共用一套代码、一键升级”的公有云美梦中。
然而，当业务逐渐向高端 B 端市场（如大型公立学校、教育局、三甲医院）拓展时，客户往往会带着大笔预算提出极其强势的“私有化部署”要求。更致命的是，A 学校要求在首页加上他们校长的寄语和特有的校徽排版；B 医院要求系统必须深度对接他们内部极其古老的 HIS 系统接口。
短短半年时间，原本清爽的代码库里可能就被塞满了无数个 if (school == 'A') 和 if (school == 'B')。每一次发版，都会因为某段专供 A 学校的代码不小心在 B 医院生效，而引发严重的生产事故。
本文将探讨，面对私有化交付中难以避免的碎片化定制，如何利用 Docker 容器化与私有镜像仓库（Registry）建立一套极其硬核的版本控制与分发体系。
噩梦：靠 Git 分支管理定制化（极不推荐）
很多团队最初尝试的方案，是为每一个客户在 Git 上拉一个专属的分支。
主分支叫 main，A 学校叫 feature-school-A，B 医院叫 feature-hospital-B。
灾难很快就会降临：
当研发团队在主分支上修复了一个极其核心的量表算分 Bug，或者新增了一个牛逼的导出功能时，噩梦开始了。
开发人员必须手动把这段代码通过 git cherry-pick 或者 merge，痛苦地同步到那几十个客户的专属分支里。由于每个分支都改过不同的底层代码，冲突合并（Merge Conflict）会满天飞。这不仅极其消耗人力，而且极易漏合、错合代码。
极客方案：主干开发与基于环境变量的特征开关（Feature Toggle）
正如橙星云研发团队在经历血泪教训后得出的真理：代码库只能有一个！所有客户的代码必须全部合并在同一个主干（Master）中。
那么如何实现不同客户看到不同的界面和功能？答案是：特征开关（Feature Toggle）结合设计模式。
如果 A 学校需要特殊的首页，我们不直接改原首页，而是新建一个 SchoolAHomePage.vue。
在代码打包时或者运行时，通过读取服务器上的环境变量（如 CUSTOMERCODE=SCHOOLA），系统自动将路由指向这个特供页面。
同样，如果 B 医院对接了特殊的 SSO，我们利用“策略模式（Strategy Pattern）”，将各个医院的 SSO 逻辑封装成独立的类，运行时根据环境变量自动动态注入对应的策略。
容器分发：搭建企业级 Docker Registry
代码合并后，下一个难关是如何把这些不同的配置送到客户现场那断网的私有服务器上。
绝对不能让实施人员拿着 U 盘，把源码或者一堆 Jar 包拷贝到客户机房里，现场去装 Node.js 和 Java 环境变量。客户现场的环境比地雷阵还复杂，这么做注定失败。
我们必须全面拥抱 Docker 容器化交付。
- 镜像构建（Build）：在公司的 CI 流水线中，我们将编译好的代码、极其精简的 Alpine Linux 操作系统、以及所有必需的环境依赖，打包成一个极其标准化的 Docker 镜像。
- 私有 Registry：公司内部利用 Harbor 或阿里云容器镜像服务，搭建一个私有的 Docker Registry。每次构建后，将镜像打上版本标签（如
psy-backend:v2.1.5）推送到仓库中。 - 现场拉起：实施人员到了客户现场，只需要执行两行极其简单的命令：
- 导入公司带过去的镜像压缩包（如果是彻底断网环境）。
- 写一个简单的
docker-compose.yml文件，在里面配置好属于该客户的CUSTOMER_CODE环境变量，然后执行docker-compose up -d。
在一分钟之内，整个系统（包括前端、后端、Redis、Nginx）会在客户那台破旧的服务器上以极其一致的标准姿态瞬间启动。
总结
在企业级 B 端私有化部署的深水区，代码的定制化与版本碎片化是无法逃避的宿命。
通过坚守单一代码主干，利用高级的特征开关隔离定制逻辑，并利用 Docker Registry 将系统封装成无视物理环境差异的标准化“集装箱”，技术团队彻底消灭了“在我的电脑上明明是好的”这种实施梦魇。这不仅是一场技术架构的升级，更是一次交付工程管理的降维打击。