uniapp 低代码 vs 传统 uniapp 开发：什么时候值得用
结论先行：低代码（Low-Code）不是传统开发的替代品，它在「页面多、变化快、人少、周期紧」这四个条件同时成立时才明显划算。只要其中两项反转——页面少、需求稳定、团队有富余前端、交付周期宽松——手写 uni-app 的综合成本更低。下面用四个维度和三条阈值把这件事量化，避免选型会开成立场之争。
一、四维判断法：把争论变成打分
不要问「低代码好不好」，要问「这个项目落在哪个区间」。四个维度各给 1 分，得分 3 分以上偏低代码，2 分以下偏手写。
| 维度 | 偏向低代码的区间 | 偏向手写的区间 |
|---|---|---|
| 页面数量 | 30 个以上，且以标准表单与列表为主 | 10 个以内，或大量非常规页面 |
| 变更频率 | 每月都有字段或流程调整 | 需求冻结后很少改 |
| 团队规模 | 1~5 人，无专职前端或前端兼职 | 5 人以上专职前端，有组件库沉淀 |
| 交付周期 | 4 周以内要上线首版 | 3 个月以上，允许打磨 |
这个打分的意义在于暴露矛盾。典型反例是「页面很多、但交互极特殊」——页面数量给低代码加分，页面类型又拉回手写，最终得分落在中间，说明该走混合路线，而不是二选一。
团队规模这一维度的具体用法，见uniapp 低代码适合什么规模的团队。
二、分界线：三条可执行的阈值
- 页面 30 个、字段变更每月 5 次以上：低代码的边际成本优势开始显现。手写模式下，每次改字段意味着改页面、改校验、改联调，重复劳动占大头。
- 团队前端少于 3 人、且要同时维护 2 个以上端：低代码的多端一致性能力可以省掉大量适配工作。人手越少，这层收益越明显。
- 首版交付要求 4 周以内：手写方案通常要 1 周搭基础设施，剩余 3 周做业务，风险集中在联调阶段。低代码把这 1 周压缩到 1~2 天。
反过来，三条阈值的反面同样成立：页面少于 10 个、需求半年不变、团队有 5 人以上前端，手写的长期收益更高，因为架构、性能与可测试性都由自己掌控。
三、成本对比：不只算人天
| 项目类型 | 传统开发估算 | 低代码估算 | 更适合 |
|---|---|---|---|
| 内部审批工具（20 页面） | 25~35 人天 | 8~12 人天 | 低代码 |
| 会员商城小程序（40 页面） | 60~80 人天 | 30~45 人天 | 视交互复杂度 |
| 品牌展示站（8 页面） | 10~15 人天 | 5~8 人天 | 低代码 |
| 强交互应用（实时、地图、音视频） | 90 人天以上 | 不适用或需大量手写 | 手写 |
人天按一线城市中级前端 800~1500 元/人天折算，仅作规划参考。表里没算进去的是两类隐性成本：低代码的授权费与平台学习成本，手写的架构维护成本与人员流动风险。前者是一次性的、可见的；后者是持续的、容易被忽略的。做预算时把这两项都列出来，结论通常会更冷静。
四、混合路线：低代码搭壳 + 手写补核
多数项目的最优解不在两端，而在中间。可执行的组合方式有三种：
- 低代码做外围、手写做核心：用低代码快速产出活动页、帮助中心、设置页等边缘页面，把首页、交易链路、核心交互留给手写。
- 低代码做原型、手写做交付：先用低代码在一周内产出可点原型，拿去验证需求，确认后再按原型手写正式版本。
- 低代码做运营、手写做底座：底座由前端团队维护组件库与接口层，运营侧用低代码拼装页面，二者共享同一套设计规范。
混合路线的成败取决于一件事：边界是否清晰。哪部分归平台生成、哪部分归手写，必须在项目启动时写进约定，否则半年后没人说得清某个页面到底该在哪边改。
设计稿直接转页面的效率对照，见uniapp 低代码怎么把设计稿转成页面。
五、什么时候坚持手写
- 性能敏感：长列表、复杂动画、大量图片流，需要逐帧优化。
- 平台能力密集：需要频繁调用原生插件、硬件接口、离线缓存。
- 长期演进：产品路线图超过两年，架构需要持续重构。
- 合规要求高：代码需要完整审计、可测试、可静态扫描。
这些场景里，低代码省下的前期时间，会在中后期以调试与适配的形式还回去。
FAQs
Q1：用低代码做的项目，性能一定比手写差吗？
A：不一定，但可控性更低。标准页面两者差距很小，复杂页面差距明显。判断方法是拿项目里最重的一个页面做真机测试，看首屏时间与滚动帧率，而不是看平台宣传数据。
Q2：小团队是不是必须用低代码？
A：不是必须，但性价比通常更高。3 人以下团队手写多端应用，基础设施就要吃掉 20%~30% 的工期；低代码能把这部分压缩，把人力集中到业务上。
Q3：低代码项目后期转手写，成本大概多少？
A：取决于导出能力。能拿到可读工程的项目，迁移主要是替换平台特有模块，约为重写的 30%；只拿到打包产物的项目，基本等于重写。