01-多端项目版本管控痛点：SaaS后端/安卓工控/小程序版本冲突问题解析

先给新手朋友理一理，什么叫"多端项目"。

拿我们智慧农业 + 无人售货柜的业务来说，一套完整的无人售货柜系统，背后涉及三端甚至更多端的并行开发：

三端开发语言不同、部署节奏不同、发布周期不同，但它们之间有强耦合的协议依赖------后端API改了字段，安卓固件没跟上，货柜就识别不了商品；小程序支付流程变了，后端回调没改，用户就扣不了款。

这就是多端项目版本管控的核心痛点：你改了一个端的代码，另外两个端不知道。

说个我们实际踩过的坑。

某次迭代，后端同学把"开门"接口的返回值从：

json 复制代码

{
  "code": 0,
  "msg": "success",
  "data": {
    "doorId": "A001",
    "status": "open"
  }
}

改成了：

json 复制代码

{
  "code": 0,
  "msg": "success",
  "data": {
    "door_id": "A001",
    "door_status": "opened",
    "open_time": 1700000000
  }
}

看起来只是驼峰改下划线、加了几个字段？但对于安卓固件来说，doorId 变成了 door_id，Gson反序列化直接拿到null，货柜门开了但状态没回传，用户取完东西关门后结算不了，直接死锁。

更要命的是------后端这个改动是周五下午合的，安卓固件同学根本不知道，下周一拉了最新后端代码联调才发现问题。而小程序那边因为只用到了code和msg字段，测试通过了，大家以为没问题，结果安卓固件一上线就炸了。

这就是典型的"版本不对齐"问题。

三端之间通过HTTP/REST或WebSocket通信，接口协议就是"契约"。但这个契约没有统一管理------后端改了接口，可能只口头告诉了小程序同学，安卓固件同学被遗忘。没有契约测试，没有接口版本号，出了问题全靠背锅。

后端可以随时热更新，但安卓固件推包到几百台货柜需要时间，小程序还要过微信审核。后端发了新版API，但旧版固件还在线上跑，这时候后端必须做向下兼容，否则就是灾难。

很多团队初期没有分支规范，所有人在master上开发，或者每个人一个分支想怎么合怎么合。三端代码如果还在同一个仓库（monorepo），后端合并代码可能影响安卓固件编译；如果分仓库，跨仓库的版本对齐又没人管。

三端联调需要一个稳定的环境。但后端开发者在测试环境频繁部署，安卓固件同学拉代码发现后端接口又变了，小程序同学刚调通又被后端的改动搞挂。没有版本对齐机制，联调就是一场噩梦。

很多团队说"我们用了Git啊"，但实际用法是：

Git只是工具，没有流程规范的Git，和U盘拷代码没有本质区别。

基于上述痛点，我们需要一套体系化的方案：

分支模型规范：明确哪些分支做什么用，谁能在上面提交，什么时候合并------这是本系列第3、4篇的内容
接口契约管理：后端API变更必须走版本号，跨端通知机制要建立
版本对齐机制：三端发版前做版本对齐检查，确保协议匹配
Tag与版本号管理 ：每次发布打Tag，v1.2.0-backend、v1.2.0-firmware、v1.2.0-miniapp，三端版本号可追溯
CI/CD流水线：自动化构建、自动化测试、自动化部署，减少人工失误

本系列将从Git核心原理出发，逐步讲解企业级分支规范、多端分支策略、DevOps实战，最终给出一套可落地的多端项目版本管控方案：

搞懂了这套体系，多端项目的版本冲突问题就不再是"靠人提醒"，而是"流程兜底"。后面几篇我们逐步展开，从Git底层原理到企业级实战，一条龙讲透。