校园外卖项目讨论“自营还是加盟”时，容易先谈品牌和费用，却把账号、域名、数据、权限、接口和退出交接留到最后。真正上线后，支付主体、小程序管理员、服务器账号、商家数据和骑手权限分别由谁掌握，会直接影响日常配置、故障处理和后续迁移。
这篇文章不替项目方选择经营模式，而是给出一份可以写进需求、合同附件和验收用例的技术清单。
一、先把经营关系和软件交付拆开
自营、合作运营或品牌合作回答的是“谁负责经营、使用什么品牌、怎样分工”；SaaS、独立品牌、私有化部署、源码安装和定制开发回答的是“系统怎样交付”。两组概念有关联，但不能互相替代。
采用合作运营不等于所有技术账号必须由合作方持有；采用自营也不等于项目方必须自己维护服务器和代码。正确做法是逐项确认资产归属、管理权限、操作责任和退出交接。
二、建立一张技术资产登记表
- 品牌名称、域名及备案主体；
- 小程序、公众号、App及对应管理员；
- 支付商户号、结算账户和证书；
- 服务器、数据库、对象存储、CDN和证书；
- 短信、地图、打印、语音通知等第三方账号；
- 用户端、商家端、骑手端和平台后台账号；
- 源码、构建产物、配置文件、接口文档与版本记录；
- 数据备份、日志、监控和告警入口。
每一项至少写清“登记主体、实际管理员、费用承担、修改审批、交付证据、退出处理”六个字段。只有一个账号和密码的口头交接，不等于资产已经可控。
三、把角色权限落到组织和数据范围
校园外卖常见角色包括总部管理员、校区管理员、商家、骑手、客服、财务和运营。权限设计不能只判断“能不能看到菜单”，还要同时限制组织范围、数据范围和可执行动作。
例如，校区管理员可以维护本校商家和配送规则，但不应直接读取其他校区订单；客服可以查看售后所需信息，但不应修改结算规则；财务可以生成对账单，但大额调整应保留审批和操作日志。
验收时建议用不同角色账号执行同一组越权测试：跨校区查询订单、修改其他商家结算、导出超出范围的用户数据、替他人重置权限。系统拒绝操作并留下日志，才算权限边界真正生效。
四、数据不只是一份导出文件
需要确认的数据至少包括用户、商家、商品、订单、退款、配送、账单、结算、提现和操作日志。交接清单应说明：
- 哪些数据可以导出；
- 导出格式、字段说明和时间范围；
- 图片、附件和日志是否包含；
- 数据备份由谁执行、保留多久；
- 迁移或退出时怎样核对数量和完整性；
- 涉及个人信息时怎样控制用途、权限和留存。
“数据归项目方所有”是一句原则，字段清单、导出样例、校验方法和删除责任才是可验收的实施要求。
五、接口和密钥要有独立交接项
支付、短信、地图、打印和第三方订单接口通常包含应用ID、密钥、证书、回调地址、IP白名单和调用额度。建议为每个接口登记用途、申请主体、生产/测试环境、密钥保管人、轮换周期、回调地址、额度告警和停用流程。
六、把退出交接设计成一次可执行演练
- 导出指定时间范围的订单和账单；
- 核对商家、骑手和校区数量；
- 移交域名、小程序、支付和云资源管理员；
- 轮换接口密钥与后台高权限账号；
- 验证备份可以恢复；
- 停用旧账号并检查操作日志；
- 形成双方确认的交接记录。
如果某项资产受平台规则限制不能直接转移，就应提前写明可采用的变更主体、重新申请、数据迁移或授权调整方案。
七、用八类用例做最终验收
建议至少覆盖新建校区、商家入驻、骑手授权、跨校区越权、支付配置变更、订单数据导出、接口密钥轮换、退出交接演练。每类用例记录前置条件、操作角色、预期结果、日志证据和失败处理。
微订覆盖用户、商家、骑手和平台管理等角色，可按校园项目组合外卖、跑腿、商城、点餐等模块，并支持SaaS、独立品牌、私有化部署和个性化开发。具体账号归属、接口、部署、数据导出和交接范围，仍应结合项目需求、产品演示和合同清单逐项确认。
结论
经营模式可以调整，技术资产边界不能模糊。先建立资产表，再设计角色权限、数据清单、接口密钥和退出演练，项目方才能判断自己实际掌握了什么、合作方负责什么、出现变化时怎样平稳交接。
