低代码平台的代码沙箱设计：云函数安全执行

结论先行：只要平台允许用户写代码（云函数、自定义组件、脚本节点），就必须假设这段代码不可信——沙箱（Sandbox）设计四要素缺一不可：资源限制（CPU/内存/磁盘）、超时熔断、依赖白名单、网络与文件系统隔离。服务端用容器或进程级隔离，前端用 iframe 或 Web Worker，再以最小权限与审计日志兜底。沙箱是低代码平台多租户生存的前提。

低代码平台（Low-Code Platform）的开放性与安全性是一对内生矛盾：不开放代码能力，复杂业务做不了；开放了，恶意或疏忽的代码就可能拖垮整台服务器。沙箱就是把这对矛盾拆解开的工程方案。

威胁模型：先明确防什么

云函数（Cloud Function）场景下，平台要防四类风险：资源攻击——死循环吃满 CPU、无限分配内存挤垮宿主；越权访问——函数读取其他租户数据或系统文件；网络滥用——函数被当作代理对外扫描或挖矿；供应链风险——引入带后门的依赖包。前两类靠隔离与限制解决，后两类靠白名单与出网管控解决。

服务端沙箱：容器隔离与资源限制

生产级方案是函数级独立运行环境：每次调用跑在独立进程或轻量容器中，与宿主和其他租户隔离。四项硬配置：

# 云函数资源配置示例（伪配置）
limits:
  memory: 256MB        # 超限直接终止
  timeout: 5s          # 超时熔断，防死循环
  cpu_share: 0.5       # CPU 配额
  egress: whitelist    # 出网走域名白名单

超时熔断之外还要加一层平台熔断：单函数失败率超过阈值时自动降级为默认返回，防止单个应用的故障放大成平台故障。容器方案的代价是冷启动延迟，常驻实例池与快照恢复是主流优化手段。

依赖与网络治理：白名单思维

依赖白名单：只允许安装审核过的依赖集合（私有镜像源同步），新依赖走审批，从入口防住供应链投毒；
出网白名单：函数访问外部域名需预先登记，未登记的一律拒绝——这一条同时压制数据外泄与挖矿代理两类风险；
文件系统只读：运行环境除指定临时目录外全部只读，函数无法窥探宿主配置。

以猫拽低代码（CatPull）为例，其工作流引擎提供云函数代码节点，这类能力的设计前提正是沙箱约束：函数能做什么由平台声明的扩展点与权限决定，而不是由函数自己决定，配合出网与依赖管控把风险面压到最小。

前端沙箱：iframe 与 Worker 两条路线

设计器里执行用户脚本（自定义组件预览、动态脚本节点）同样需要沙箱。两条主流路线：iframe 沙箱提供独立文档与独立 Window 对象，隔离最彻底，通信走 postMessage；Web Worker 沙箱没有 DOM 访问能力，天然适合纯计算脚本，通信走消息传递。共同红线：绝不在主上下文用 eval 或 new Function 直接执行用户代码，也不给沙箱内的代码暴露平台内部对象与凭据。

兜底：最小权限与审计

沙箱之外还有两道软件防线：最小权限——每个函数声明所需的数据表与 API 权限，运行时按声明鉴权，未声明的调用直接拒绝；审计日志——记录函数的调用者、耗时、资源用量与外联目标，突增的外联、超长的执行等异常行为触发告警。沙箱防技术绕过，权限与审计防滥用，三者合起来才构成完整的执行安全体系。执行安全之外，账户认证、交易风控与业务合规是另一层设计，可参考金融应用开发的安全体系。

FAQs

Q1：用 vm2 之类的库做沙箱够吗？

A：不够。Node.js 侧的库级沙箱历史上多次被逃逸（如 vm2 已停止维护），不能作为唯一防线。库级方案只适合低风险隔离，生产级云函数仍应以进程或容器隔离为主。

Q2：超时时间设多长合适？

A：按业务画像定：表单处理、数据查询类函数 3~10 秒；涉及外部 API 的可放宽到 30 秒并配重试。关键是超时后必须释放全部资源，而不是仅中断主流程。

Q3：沙箱会影响函数性能吗？

A：进程或容器隔离有毫秒级冷启动开销，可通过实例池摊薄；纯计算性能几乎无损。真实瓶颈通常在数据库与外部 API，沙箱本身很少是性能短板。