多人协作与版本管理

低代码应用的三个「多人」维度：
  1. 多人同时编辑：建模的、画页面的、配流程的
  2. 多环境流转：开发 → 测试 → 生产
  3. 多版本并存：灰度期间新旧版本同时在跑

没有版本管理的后果：
  - 改错了无法回退，只能手工反向改
  - 不知道谁在什么时候改了什么
  - 环境之间靠「导出 JSON 再导入」同步，必然漂移

一个典型应用的协作角色：
  建模者：数据模型、字段、关系（改动影响面最大）
  搭建者：页面、表单、布局（改动最频繁）
  流程配置者：流程节点、审批规则（改动最敏感）
  权限管理员：角色、数据范围（改动最容易出事）

Schema diff 的层级：
  实体级：新增 / 删除 / 重命名实体
  字段级：新增 / 删除 / 改类型 / 改约束
  关系级：新增 / 删除引用
  视图级：页面节点的增删改
  逻辑级：表达式、流程节点的变更

目标：每一级都产出「结构化变更列表」，而不是文本差异

type Change =
  | { op: 'add'; path: string; value: unknown }
  | { op: 'remove'; path: string; old: unknown }
  | { op: 'update'; path: string; from: unknown; to: unknown }
  | { op: 'move'; from: string; to: string };

合并需要三个输入：
  base：分支点时的版本
  ours：当前分支的修改
  theirs：目标分支的修改

按路径归并规则：
  ours 改了、theirs 没改 → 取 ours
  ours 没改、theirs 改了 → 取 theirs
  两边都改且值相同       → 取该值
  两边都改且值不同       → 冲突
  一边删除、一边修改     → 冲突（删除 vs 修改）

function threeWayMerge(base: Schema, ours: Schema, theirs: Schema): MergeResult {
  const b = flatten(base), o = flatten(ours), t = flatten(theirs);
  const merged: Record<string, unknown> = {};
  const conflicts: Conflict[] = [];
  for (const path of new Set([...Object.keys(o), ...Object.keys(t)])) {
    const bv = b[path], ov = o[path], tv = t[path];
    if (eq(ov, tv)) merged[path] = ov;
    else if (eq(ov, bv)) merged[path] = tv;          // ours 未改
    else if (eq(tv, bv)) merged[path] = ov;          // theirs 未改
    else conflicts.push({ path, base: bv, ours: ov, theirs: tv });
  }
  return { merged: unflatten(merged), conflicts };
}

结构性冲突（有机会自动可解）：
  - 两边新增了同名但定义不同的字段 → 需人工选
  - 一边改字段类型、一边改字段 label → 可自动合并（不同属性）

语义性冲突（自动不可解）：
  - 一边删除字段、一边在表达式里引用该字段 → 必须人工
  - 一边把字段类型从 string 改成 number、一边写入字符串默认值
  - 两边都改了同一流程节点的分支条件

解决策略：
  1. 能自动合并的自动合并，把待人工处理的冲突数降到最小
  2. 冲突在可视化界面里逐条呈现（base / ours / theirs 三栏对照）
  3. 每条冲突提供「保留我的」「采用对方」「手工编辑」三个动作
  4. 冲突未全部解决前，禁止提交

完整分支模型（向 Git 借思路，但更轻）：
  main（生产）
   └── release/*（发布分支，冻结）
        └── feature/*（功能分支，可多人协作）

简化版（多数低代码平台够用）：
  dev（开发，随时改）
  staging（测试，从 dev 发布）
  prod（生产，从 staging 发布）

发布 = 把某个版本的 Schema 快照「晋升」到下一环境
  不是「复制当前状态」，而是「发布指定版本」
  这样才能保证「测试通过的版本 = 上线的版本」

// 发布：把指定版本晋升到目标环境，而不是复制当前工作区
async function promote(appId: string, version: number, env: string) {
  const snap = await snapshotStore.get(appId, version);   // 不可变快照
  if (!snap) throw new Error(`版本 ${version} 不存在`);
  await db.update('app_env')
    .set({ version, promoted_at: new Date() })
    .where({ app_id: appId, env });
  await audit.log({ appId, env, action: 'promote', version });
}

三个状态：
  草稿（draft）：只有作者可见，不要求完整性
  已发布（published）：所有用户可见，通过完整校验
  灰度（canary）：部分用户可见，与已发布版本并存

灰度实现：
  应用版本 + 用户分桶 → 决定该用户加载哪个版本的 Schema

function resolveVersion(appId: string, user: User): number {
  const app = appStore.get(appId);
  if (!app.canary) return app.publishedVersion;
  const bucket = hash(user.id) % 100;
  return bucket < app.canary.percent
    ? app.canary.version
    : app.publishedVersion;
}

预览的三种形态：
  1. 草稿预览：带一次性 token 的链接，只对作者有效
  2. 版本预览：指向某个历史版本的只读视图
  3. 分支预览：feature 分支的独立预览环境

预览环境的三条禁令：
  不能写生产数据
  不能触发真实流程（会发通知、会占用审批人）
  不能调用生产连接器（会打款、会发短信）

三种并发模型：
  A. 悲观锁：进入编辑即锁定，他人只读
     简单，但协作体验差，锁忘记释放会阻塞别人
  B. 乐观锁：提交时带版本号，冲突则拒绝
     适合低频编辑，冲突时提示「有人已修改，请刷新」
  C. 实时协作：CRDT / OT，多人同时编辑即时同步
     体验最好，但元数据是树形结构，CRDT 实现复杂

// 乐观锁：提交时校验版本
async function save(appId: string, schema: Schema, expectedVersion: number) {
  const rows = await db.update('app_schema')
    .set({ schema, version: expectedVersion + 1 })
    .where({ app_id: appId, version: expectedVersion });
  if (rows === 0) throw new ConflictError('版本已过期，请刷新后重试');
}

审计日志要记录：
  谁（user）
  何时（timestamp）
  在哪个环境（env）
  改了什么（结构化变更列表，不是整份快照）
  为什么（关联的需求 / 工单号）
  结果（成功 / 被拒 / 冲突）

CREATE TABLE app_change_log (
  id          bigserial PRIMARY KEY,
  app_id      varchar(36) NOT NULL,
  env         varchar(16) NOT NULL,
  actor       varchar(64) NOT NULL,
  version     int NOT NULL,
  changes     jsonb NOT NULL,      -- Change[] 结构化列表
  reason      varchar(256),
  created_at  timestamptz NOT NULL DEFAULT now()
);
CREATE INDEX idx_change_app_time ON app_change_log(app_id, created_at DESC);

回滚的三个层次：
  1. 配置回滚：把 Schema 指回旧版本（秒级，推荐）
  2. 数据回滚：Schema 变更伴随的数据迁移回退（难，需备份）
  3. 混合回滚：配置回滚 + 数据向前兼容（最现实）

前提：Schema 变更必须「向后兼容」
  新增字段（可空）→ 安全
  删除字段         → 先停用，再延迟删除
  改字段类型       → 加新字段迁移，而不是原地改

-- 配置回滚：把环境的版本指针指回上一个已发布版本
UPDATE app_env
SET version = :previousVersion, rolled_back_at = now()
WHERE app_id = :appId AND env = :env;

两种协同方式：
  A. 元数据为主，仓库做备份：定期导出 Schema 到 Git，用于审计与灾备
  B. 仓库为主，平台做编辑：Schema 存在仓库里，平台通过 PR 提交变更

A 的问题：Git 里的是快照，不是真相，容易漂移
B 的好处：复用现有研发流程（评审、CI、发布）
B 的代价：Schema 必须序列化成稳定的文本格式

function serialize(schema: Schema): string {
  return JSON.stringify(sortDeep(schema), null, 2) + '\n';
  // sortDeep：按 key 字典序递归排序，数组保持原序
  // 不带时间戳、不带构建号、不带随机 id
}