选型的账不能只算第一年。

低代码平台的优势集中在前期。拖拽配置、预置组件、内置数据模型，几周就能把流程跑起来，不需要组建完整的研发团队。对于内部管理类的应用、流程审批、数据采集这些场景，够用而且省心。

代价出现在迭代阶段。表层样式与简单流程的调整依然方便，但一旦涉及复杂的业务规则、与外部系统的深度对接、对性能有明确要求的计算逻辑，就得绕开平台去写扩展代码，或者干脆放弃。平台内的数据模型是固定的，两个有些特别的需求往往要在现有结构上凑，凑出来的实现维护起来别扭。更要紧的是迁移成本，业务做大之后想换到自主可控的技术栈，数据导出、逻辑重写、接口重建几项加起来，投入未必低于重新开发一遍。

原生开发的路子相反。起步慢、投入高，团队要配置齐全，第一版的周期通常以月计。可它的灵活度摆在那里，业务逻辑改动、第三方接口接入、性能优化都能按需要做，长期看技术资产的沉淀在自己手里，后续的扩展不受平台能力边界限制。

两者之间还有一条中间路线，前端用跨端框架保证多端一致，后端按常规服务化架构搭，把移动端与后台分开演进。这种结构在实际项目里比较常见，兼顾了上线速度和后期可控性。

还有一种做法是把两类技术放在一起用。面向内部的流程工具、数据填报、简单审批交给低代码，快速上线也便于业务自己调整；面向客户的交易链路、核心业务系统用原生开发，保证性能与自主可控。两者之间通过接口交换数据，边界清晰，各自的成本也更容易核算。数据资产归属于哪一方，签约时就要写明。

判断的依据可以落到两个问题上：业务未来一年会不会频繁调整规则？数据与业务流程是否属于自身的核心资产？两个答案都偏向肯定，原生或混合架构更合适；答案偏向否定，低代码能更快看到结果。