前面几篇文章已经把 FastGPT 的部署、安全和可观测体系梳理了一遍。到这里，我们再看一个更贴近日常运维的问题：当用户把一个工作流设计得很复杂、把文件批量导入得很大、或者同时发起大量请求时，系统靠什么避免资源被打满？这一篇关注的不是单点性能优化，而是 FastGPT 在源码里布置的稳定性边界：工作流不能无限运行。循环和并行节点不能无限展开。Worker 和训练队列都有并发阈值。请求体、上传文件、外部 HTTP 响应都有大小限制。Redis、Code Sandbox、Agent Sandbox 也有各自的资源保护。这些限制看起来分散在不同模块里，但它们共同服务于一个目标：把用户配置、外部输入和后台任务都限制在可预测范围内。一、从环境变量看全局资源边界FastGPT 的大部分性能与稳定性参数都集中在packages/service/env.ts。这个文件不是普通的常量表，而是运行时配置的 schema。它既定义默认值，也定义合法范围，还会在启动时做跨字段校验。源码位置：packages/service/env.ts projects/app/.env.template deploy/version/v4.15/docker-compose.template.yml在.env.te