从手写 uniapp 迁移到低代码的路径与代价
迁移不是把代码复制进设计器，而是把"页面写在代码里"改成"页面写在配置里"。正确路径是四步：先盘点页面，再评估哪些能拖拽化，然后按模块渐进迁移，最后准备好回退预案。代价主要落在人身上：调试方式变了、代码评审对象变了、团队习惯要重建。20 页的项目按 15~40 人天估算，低于 10 页的项目不建议迁。
一、先判断该不该迁
三个前提同时成立再动手：
- 页面结构以表单、列表、详情为主，定制交互占比低于 30%。
- 后续 6 个月仍有持续的页面新增需求，而不是进入维护期。
- 团队愿意接受"配置也是代码"的评审方式，有人能长期维护平台。
任一不成立，迁移的投入大概率收不回来。
二、四步路径
第一步：页面盘点
把现有页面逐页登记，至少包含 5 个字段：页面路径、页面类型、日均访问量、最近一次改动时间、依赖的原生能力。盘点的目的是排序，不是建档：先迁访问量高、改动频繁的页面，收益最快；访问量低又长期不动的页面留到最后，甚至可以不迁。
第二步：可拖拽化评估
把页面分四类，分别给不同策略：
- A 类（纯展示与表单）：可直接拖拽化，迁移成本最低。
- B 类（列表加筛选）：可拖拽化，但筛选逻辑要落到工作流或云函数，需要额外设计。
- C 类（复杂交互）：例如手势、动画、自定义绘制，保留手写，只把外围页面迁移。
- D 类（原生能力依赖）：例如蓝牙、NFC、特定硬件，保留手写并封装成组件供低代码页面调用。
按经验，A、B 两类通常占页面总数的 60%~75%，这部分决定了迁移能省多少。
第三步：渐进迁移
不要一次性切换。按模块切分，每个模块迁完后与原页面并行运行 2 周，用同一批真实用户流量对比关键指标。灰度比例从 10% 起，观察 3 天无异常再放到 50%，最后全量。并行期的作用是让问题在低流量时暴露，而不是在全量后才发现。
第四步：回退预案
回退方案要在迁移前写好，至少包含三条：
- 旧页面代码保留至新页面稳定运行 30 天，不删分支。
- 提供按用户维度切换的开关，出问题 10 分钟内可回退。
- 数据结构变更必须双向兼容，新配置读写不能破坏旧代码读取。
没有这三条的迁移，等于把线上稳定性押在第一次上线。
三、代价清单
| 代价项 | 具体表现 | 量化估算 | 缓解办法 |
|---|---|---|---|
| 重写成本 | 页面结构、样式、交互需重新配置 | 每页 0.5~2 人天 | 优先迁 A、B 类，C、D 类保留手写 |
| 调试方式变化 | 从断点调试变成看配置与日志 | 每人 2~3 天适应期 | 建立配置版本对比与日志检索规范 |
| 评审方式变化 | 代码评审变成配置与物料评审 | 每页多 0.2~0.5 小时 | 用清单代替逐行看，聚焦状态与权限 |
| 团队习惯 | 前端习惯写代码，排斥拖拽 | 首月效率下降 20%~30% | 先在小模块做出可见收益再推广 |
| 平台依赖 | 升级与故障需等平台侧处理 | 每年 3~10 人天 | 保留手写兜底能力，关键页不做纯配置 |
迁移后的许可与订阅成本，见uniapp 低代码工具价格对比：免费版、订阅与私有化。
四、工期估算
按页面数量给三档参考：
- 10~20 页：15~25 人天，其中盘点与评估约 3 天。
- 20~50 页：30~60 人天，含 2 周双跑期。
- 50 页以上：按模块拆分，每批不超过 20 页，单批 10~20 人天。
工期里最容易被低估的是"调试方式变化"带来的适应期，这部分通常占总工期的 15%~25%。
FAQs
Q1：迁移后旧代码还能保留吗？
A：建议保留 30 天以上再清理。并行期内旧页面是唯一可靠的回退路径，删掉分支等于放弃回退能力；30 天后确认新页面稳定、无数据兼容问题，再按模块归档。
Q2：哪些页面一定不要迁？
A：依赖原生硬件能力、含复杂手势或动画、以及长期不改动的页面。这三类迁移收益低、风险高，保留手写并封装为组件供其他页面调用是更稳的做法。
Q3：迁移期间要不要停止新需求？
A：不要停，但要分流。新需求优先用低代码实现，旧页面只做必要修复，这样迁移与新功能可以同时推进，代价是并行期团队需要多 1 人协调页面归属。