多个项目怎么安全合并？先适配，再切换

当一个业务从单一工具发展成浏览器服务、内容系统、管理后台和移动端，团队迟早会遇到一个问题：要不要把多个项目合并成一个项目？

真正危险的并不是"项目多"，而是还没证明新入口能承接旧能力，就先复制全部源码、停掉旧服务，甚至删除旧仓库。更稳妥的路线是：先建立窄适配层，让统一项目能够受控调用旧能力；再用同一输入做双轨验证；最后按能力逐项切换。删除旧项目是迁移完成后的结果，不是迁移开始时的动作。

为什么直接搬代码经常失控

多个项目通常不只是目录不同。它们可能各自拥有数据库、文件工作区、登录会话、环境变量、定时任务和恢复策略。直接复制源码会同时引入四类风险：

边界丢失：原来由不同服务隔离的权限和凭据，被放进同一个进程。
状态冲突：两套程序同时写同一份草稿、数据库或缓存，谁是事实来源变得不清楚。
验收失真：新项目能启动，不等于原有业务链路已经迁移。
回滚失效：旧仓库和旧数据过早删除，问题出现后只剩"继续修新系统"这一条路。

所以第一步不是搬代码，而是冻结合同：每项能力的输入、输出、状态、秘密、失败方式和验收条件分别是什么。

用端口与适配器建立迁移缓冲区

端口描述统一项目需要什么能力，适配器负责连接旧实现。应用层只依赖端口，不关心能力来自旧进程、HTTP 服务还是以后迁入的新模块。

下面是一个经过简化的 Python 示例：

python 复制代码

from typing import Protocol


class DeliveryPort(Protocol):
    def run(self, operation: str, arguments: tuple[str, ...]) -> dict: ...


class DeliveryService:
    def __init__(self, runner: DeliveryPort) -> None:
        self._runner = runner

    def execute(self, operation: str, arguments: tuple[str, ...]) -> dict:
        validate_operation(operation, arguments)
        return self._runner.run(operation, arguments)

这层抽象的价值不在于"代码更漂亮"，而在于迁移顺序变得可控：旧适配器和新适配器可以在相同端口下替换，核心用例不需要跟着重写。

适配层必须窄：只允许明确能力

迁移期最容易犯的错误，是提供一个"执行任意命令"的万能入口。它虽然接入快，却把旧项目的所有风险一起暴露给新系统。

更安全的做法是固定白名单：

python 复制代码

ALLOWED = {
    "source_a": {
        ("health",),
        ("draft", "create"),
        ("draft", "inspect"),
        ("release", "approve"),
        ("release", "publish"),
    }
}


def validate(source: str, arguments: tuple[str, ...]) -> str:
    for prefix in ALLOWED[source]:
        if arguments[: len(prefix)] == prefix:
            return ".".join(prefix)
    raise ValueError("该操作未进入迁移白名单")

白名单应按业务生命周期定义，而不是按可执行文件定义。健康检查、创建草稿、回读草稿、申请批准、执行发布是五个不同边界。新增能力需要代码审查和测试，不能靠运行时拼接字符串临时放行。

秘密不进命令行，正文不进回执

统一入口会增加可观测性，也可能意外扩大泄漏面。密码、Cookie、访问令牌和短期批准令牌不应放在命令行参数里，因为参数可能进入进程列表、终端历史或日志。需要传递时，使用短期环境变量或更窄的进程间秘密通道，并在调用完成后立即失效。

回执也应最小化。一次受控调用通常只需记录：

渠道和规范化操作名；
退出码与执行时间；
标准输出、错误输出的 SHA-256；
是否保存正文、参数和发布授权。

文章正文、客户数据、绝对工作站路径和原始命令参数不应该为了"方便审计"被复制进回执。审计的目标是证明发生了什么，不是再造一份敏感数据仓库。

双轨验证：新入口成功不等于迁移完成

第一阶段，新项目仍可调用旧实现，这只能证明"统一入口可用"。它不能证明旧项目已经可以删除。要完成能力迁移，至少要经过以下步骤：

1. 离线合同对比

给旧实现和新实现相同夹具，比较规范化输出、错误码、状态变化和幂等行为。对正文、图片等大对象比较 SHA-256，而不是只比较文件名。

2. 真实草稿回读

对外部平台或第三方系统，创建草稿后必须重新读取标题、正文、图片和分类。页面显示"保存成功"只是提交动作成功，不是数据一致性证明。

3. 重启恢复

在关键阶段重启统一入口、适配器或浏览器服务，确认未完成任务能被识别，已完成任务不会被重复执行，人工接管边界仍然有效。

4. 失败演练

主动测试超时、令牌失效、旧服务不可用、文件哈希变化和重复请求。写操作超时后不能盲目自动重放，应先查询真实状态，再决定继续或恢复。

切换与退役要设置两道门

"切换门"回答的是：新实现能否承担生产流量？"退役门"回答的是：旧实现是否已经没有独占能力和独占数据？两者不能合并成一个勾选框。

建议的切换门包括：

新旧实现对同一输入的合同结果一致；
草稿、批准、发布、回读形成完整闭环；
关键写操作具备幂等键或状态查询；
失败恢复和重启恢复已经实际演练；
日志中没有正文、凭据和客户敏感数据。

退役门还要额外确认：

所有数据库表、内容文件和回执都有迁移清单；
数量、相对路径和 SHA-256 已核对；
浏览器 Profile、登录态和秘密没有被粗暴复制；
旧项目已经只读运行一个观察期；
本地源码和远程仓库均有独立、可恢复的归档；
删除目标经过再次解析和人工确认。

只有一篇文章或一次请求成功，最多证明一条链路跑通，不能证明整个项目稳定，更不能直接触发删除。

一份可执行的迁移顺序

可以把合并工作拆成七步：

盘点能力、数据、秘密、后台任务和失败恢复方式。
冻结端口合同，为每项能力指定来源提交和验收用例。
在统一项目建立白名单适配层，只开放必要操作。
统一内容身份、修订号、哈希、批准和回执模型。
按模块逐项迁入，用离线夹具和真实草稿双轨比较。
切换新入口，保留旧项目只读观察并演练回滚。
完成数据核对、独立归档和人工复核后，再退役旧项目。

这条路线看起来比"复制目录然后修报错"慢，但它让每一步都有明确完成定义，也让团队能在任意阶段停下来，而不必押注一次性重构成功。

什么时候值得做统一项目

如果多个项目共享同一业务对象、同一内容生命周期和相同的审批边界，统一项目通常能减少重复规则和重复运维。但如果它们只是部署在同一台机器、团队成员相同，却没有稳定的共享领域，合并可能只会制造一个更大的耦合仓库。

评估官网、管理系统、小程序或 APP 的整合方案时，先画出业务对象、权限边界、外部依赖和失败恢复，再决定"合仓、模块化单体还是继续独立服务"。架构选择应该服务于交付和维护，不应只服务于目录整齐。

本文封面采用本地生成与哈希留档，更多同类技术视觉素材可在如意图库查看。想进一步理解如何把计划、实现、测试和可审计交付串起来，可以继续阅读《大鹏 Codex 智能体软件工程》。

如果你正准备把分散的官网后台、业务管理系统、小程序或 APP 合并升级，可以先整理四项材料：现有项目清单、核心数据、用户角色、最怕出错的三条流程。这四项已经足够做第一轮边界评估和迁移风险诊断。