低代码该不该支持导出源码？两种流派的技术账

结论先行：导出与托管之争的本质是"逃生通道 vs 工程可控"：导出源码给了企业对抗平台锁定（Vendor Lock-in）的底牌，但导出的代码若依赖平台私有运行时，逃生通道就是假的；托管派换来升级与体验的一致可控，却把应用生命周期押在平台存续上。开源可自托管（如 Apache-2.0 协议的猫拽低代码）是当前风险收益比更优的中间路线。

选低代码平台（Low-Code Platform）的团队，一半的顾虑集中在"会不会被绑死"。本文不站队，把两种流派的账算给你看，最后给你一张自查清单。

两种流派到底在争什么

导出派：平台应支持把应用导出为可独立部署的源码或产物，代码是用户资产；
托管派：应用托管在平台内，由平台统一升级、优化、运维，导出反而制造版本漂移。

打个比方：导出派像买房（产权在手，装修自己管），托管派像住酒店（拎包入住，但退房时什么都带不走）。两个流派都有真实成功案例，分歧点在应用的关键程度与预期寿命。而更底层的那条分岔——应用描述到底以数据还是源码形态交付，解释执行与代码生成两种流派从 5 个维度做过正面对比。

导出派的技术账：真导出与假导出

鉴别真假导出只看一个问题：导出的工程脱离原平台后，能否独立构建、独立运行？

真导出：产物是标准工程（如 Vue3 加 Vite 项目），依赖全部来自公共生态（npm 可安装），平台只作为开发期工具存在；
假导出：产物里捆绑着平台私有运行时 SDK（闭源在私源或物理文件里），一旦私源失效或授权到期，导出代码无法编译。

选购时用"断网构建测试"验证：在全新环境、不连平台服务的条件下执行构建，能跑通才是真导出。此外追问两点：导出物是否包含数据模型与工作流定义（只导页面等于只导了一半）；导出后是否支持回导同步（决定"平台开发加源码仓库"双轨并行是否可行）。

托管派的技术账：升级红利与锁定风险

托管派的红利很实在：平台统一修复缺陷、优化性能、推送安全补丁，应用方零成本受益；多租户架构下的体验一致性也有保障。风险同样清楚——平台停服、涨价、路线变更时，企业只剩"接受"或"重写"两个选项。行业参考：SaaS 形态低代码普遍按年计费，应用数量越多、存续期越长，锁定成本越高，预期运行 3 年以上的关键应用尤其要谨慎。

中间路线：开源加自托管

第三条路线近年越来越主流：平台本身开源，允许企业自托管（Self-hosted），数据与部署权在自己手里，同时保留跟随社区升级的选项。以猫拽低代码（CatPull）为例，它采用 Apache-2.0 协议开源，支持自托管与二次开发——应用的 DSL、数据、部署环境都留在企业侧，"锁定"从合同问题降级为技术问题，而技术问题总有解法。对有研发能力的团队，这是长期成本与风险最平衡的选择。

选型前必问的 5 个问题

平台停运会怎样？应用还能跑多久？
数据能否完整导出？格式是否开放？
导出源码是真是假？敢不敢做断网构建测试？
平台开源吗？协议允许商用与二次开发吗？
最坏情况下的迁移成本，算过账吗？

五个问题能回答三个以上，锁定风险基本可控；一个都答不上来，就要重新评估这家厂商。

FAQs

Q1：导出的源码质量有保障吗？

A：机器生成代码的可读性参差不齐，导出代码更适合作为"运行资产加二次开发起点"，而非直接长期维护的工程。导出后建议先补类型声明与关键注释，再排改造计划。

Q2：小团队也需要担心锁定吗？

A：看应用寿命。活动页、临时工具用托管 SaaS 完全合理；预期运行 3 年以上、承载核心业务的应用，锁定风险的账必须提前算清。

Q3：开源低代码平台等于免费吗？

A：协议开源指代码可自由使用与修改，不等于零成本。服务器、运维、二次开发人力仍是真实成本，只是议价权与数据主权回到了自己手里。