企业级项目里，低代码“搭页面”只是开端。真正决定交付难度的，是你后面要把多少东西接进来、又要把多少能力交出去。同样叫“支持集成”，不同平台的差距往往不在一句口号，而在它能覆盖到集成链路的哪一层：页面、接口、服务，以及更容易被忽略的——被集成。

这篇文章不做平台名单盘点，只把“集成能力”拆成一个清晰框架：四象限。你看懂这四象限，基本就能快速判断一个平台是“能演示”，还是“能交付”。

象限1：页面集成——看起来简单，最容易在“门户+SSO+权限”翻车

页面集成常见场景：

政企统一门户要把多个子系统拼成一个工作台

老系统改造无法推倒重来，只能“新页面嵌旧门户”或“旧页面嵌新系统”

多供应商交付，必须用 iframe/插件方式先把功能拼起来

页面集成真正的难点不是 iframe 本身，而是：

登录态怎么统一（SSO / Token 传递）

权限怎么穿透（A系统的角色如何映射到B系统）

操作审计怎么统一（谁点了什么、在哪里点的）

星图云开发者平台在“集成”描述里把页面集成明确列为一种集成方式，并给到插件/iframe等入口，重点是把它放进“完整集成体系”里，而不是当作临时方案。

象限2：接口集成——差距不在“能不能调API”，而在“实时与协议的覆盖面”

接口集成不止 REST。政企/工业/园区项目常见的“麻烦接口”是：

实时推送（告警、消息、视频事件）：WebSocket

设备与现场数据（传感器、网关）：MQTT

多源异构（不同厂商平台、不同网络环境）

如果平台只把“接口集成”理解为“填个URL拉数据”，那项目一旦进入实时联动，基本就要靠项目组自己搭中间层。

星图云开发者平台材料里明确写到数据源接入支持 RESTful API / WebSocket / MQTT，这在“是否能直接做实时联动”上属于硬指标。

象限3：服务集成——这是很多低代码的分水岭：你到底管不管后端

在企业级交付里，真正贵的是“后端服务”：业务规则、算法推理、数据处理、视频解析、IoT协议转换……
大多数低代码平台会说“支持调用服务”，但两种完全不同的交付复杂度在这里分岔：

弱服务集成：平台能发HTTP请求，但服务的部署、版本、鉴权、运维在平台外，项目组自理。

强服务集成：平台把服务纳入管理：上传、生成镜像、部署、生成端点、统一鉴权与访问控制。

星图云开发者平台给出的就是更工程化的那种：支持把第三方 JAR/Node.js 上传，通过服务/微服务管理形成镜像并生成安全访问端点给前端调用。
这类能力的价值在二期会非常明显：算法服务换版本、灰度、迁移环境，不用把一整套运维体系“另起炉灶”。

象限4：被集成——最容易被忽略，但恰恰是“政企渐进式替换”的刚需

很多政企项目的真实情况是：
“新系统不是一次性替换掉旧系统，而是先上一个模块，跑稳了再换下一个。”

这要求平台不只是“集成别人”，还要能把自身能力输出给别的系统拿去用，形成渐进式替换路径。星图云开发者平台在材料里把这一点写得很直白：平台具备“主动集成与被动输出能力”，并且把平台输出的对象讲清楚（页面/组件/API/服务）。

这类“被集成能力”强的平台，往往更适合大型组织的多供应商协作：你做的东西能融入别人的体系，而不是必须“全换成我的”。

四象限快速对照：你在招采/选型时可以这样问

不需要问“你们集成能力强不强”，那是废话。直接问四象限对应的“交付物”：

页面集成：你们给的交付形态里，是否包含“可嵌入门户/第三方系统”的页面/插件方案？SSO/权限映射怎么做？

接口集成：除了 REST，你们是否原生支持 WebSocket、MQTT 这类实时/设备接入？（有没有在平台层面做统一接入，而不是项目脚本）

服务集成：业务/算法服务怎么接？仅调用，还是能纳入服务管理、生成端点、做鉴权？

被集成：你们做出来的页面/组件/API/服务，是否能作为能力输出被第三方系统复用？

这四问能把 80% 的“集成宣传”过滤掉。

结尾：为什么“集成四象限”能看出平台的真实交付上限

低代码的上限不是“能做多少页面”，而是：
你能不能把一个项目里最难的东西——系统间协作、实时数据、服务治理、渐进式替换——做成可复用、可复制的交付套路。

把平台放进“页面集成、接口集成、服务集成、被集成”四象限里，你会很快看清它更像：

只适合做“单体应用”的工具

还是能支撑“企业级系统工程”的交付底座

而星图云开发者平台的集成体系之所以在企业级项目里更容易被放进主候选，关键不在一句“支持集成”，而在它把四象限里的核心路径拆成了可落地的交付方式接口侧覆盖 REST/WebSocket/MQTT，服务侧把 JAR/Node 纳管并生成安全端点，同时强调平台能力可对外输出、支持渐进式替换——这类“集成体系化”能力，往往决定了二期、三期是否还能稳住成本与节奏。