同样是"做一个小程序"，工程上实际存在三条完全不同的路径：模板套用、底座扩展、全定制。三者不是"贵和便宜"的差别，而是代码复用边界、数据主权和二次开发自由度的差别。很多项目复盘时发现的"当初选错了形态"，本质是没在动工前把这三条路径的工程含义拆清楚。本文从实现视角拆解三条路径的结构差异、底座扩展模式的交付流水线，以及最容易被忽略的数据层设计。
一、三条路径的分层结构：复用边界决定一切
三条工程路径的分层结构——复用边界不同，改造自由度不同
1. 模板套用：复用到整条链路
模板模式复用的是从表现层到数据层的整条链路：页面结构、业务流程、数据库都跑在平台方代码里，客户拿到的是配置项和开放接口。工程上的特征是"扩展点受限"——功能清单之外的需求没有代码入口，表现层只能换皮肤不能改结构。这类形态适合快速验证，但业务规则一旦超出清单，改造路径就走不通。
2. 底座扩展：复用通用层，重写业务层
底座扩展是介于两者之间的工程形态：登录鉴权、支付对账、权限（RBAC）、消息通知这类通用模块复用成熟实现，表现层和业务规则层按需求重写。它的价值在于把工时集中到真正差异化的业务逻辑上——分佣规则、审核流、会员体系这些"每个客户都不一样"的部分。数据库 Schema 归客户所有，业务逻辑有源码，任何团队可以接手迭代。
3. 全定制：从领域模型开始
全定制适合多端（小程序 + H5 + APP）、复杂业务规则或需要与自有系统深度对接的场景。工程起点不是页面而是领域模型：先按业务建模（实体、状态机、规则引擎），再拆分端与服务的边界，数据层预留分库分表与读写分离。多端场景下，接口层要按端做 BFF 裁剪，而不是一套接口硬喂所有端。
二、底座扩展的交付流水线：通用在前，业务在后
底座扩展交付流水线——通用模块沉淀在前，业务逻辑开发在后
1. 需求清单先于任何代码
页面清单、角色权限矩阵、业务规则逐项书面确认，是底座裁剪的输入。没有清单就动工，通用模块的取舍没有依据，后期返工集中爆发在"当初以为不用做"的模块上。
2. 底座裁剪是减法不是加法
成熟底座里的通用模块（支付、权限、短信、审核流）按需求做减法：用不上的模块直接裁掉，保留的模块按业务参数化。裁剪记录要落文档——半年后另一批人接手时，"哪些是底座、哪些是定制"分不清，维护就会误伤通用层。
3. 业务规则配置化
折扣梯度、佣金比例、审核层级这类高频变动的规则进配置表而不是硬编码，改动走后台不发版。判断一个底座扩展项目工程质量的硬指标，就是看业务规则里有多少写死在代码里。
4. 交付验收含数据导出演示
验收不只点功能，还要演示完整的数据导出：数据库结构文档、备份恢复流程、从自有服务器完整迁出的操作步骤。这三样齐了，才算把"数据主权"真正交到客户手里。
三、数据主权：锁定风险集中在数据层
数据主权对比——托管形态与自有部署的迁移自由度差异
1. 托管形态的锁定点
模板形态下业务数据存在平台数据库，导出通常受接口能力限制：能导订单列表未必能导完整关联关系，能导数据未必能导用户行为明细。停费即停服意味着迁移窗口是硬约束，一旦决定离开，能带走的东西比想象中少。
2. 自有部署的工程要求
自有部署不等于自动拥有数据主权，还要做三件事：Schema 有文档（字段含义、关联关系、枚举值口径）、备份有演练（只备份不恢复验证等于没备份）、迁移有路径（可导出为通用格式，不依赖原系统才能读的私有结构）。
3. 迁移成本在立项时就要算
从托管形态迁到自有部署，等于重做一次用户端加数据迁移；这条路径的代价远高于动工前多花时间确认形态。工程上的结论：验证期可以用托管，业务跑通后第一次大版本就应迁到自有部署——越晚迁，数据量和关联关系越复杂。
结尾：三个高频踩坑
- 拿模板形态的需求清单去评估底座扩展的工程量，两侧口径对不上，排期全盘失真
- 底座模块与定制代码没有边界文档，接手团队改业务时误伤通用层
- 备份从未做过恢复演练，出事时才发现备份文件不完整
三条路径没有绝对优劣，错的是"用 A 形态的预期去验收 B 形态的交付"。动工前把复用边界、数据归属、二开自由度三件事写进文档，比任何事后补救都便宜。
