Dify 工作流处理大量文本内存溢出，优先检查 Docker 容器内存限制并改用知识库检索替代变量传递。适用自部署场景，风险是增加架构复杂度。
先说结论：内存溢出通常由工作流变量驻留过大文本或容器限制过低导致，需结合扩容与架构调整解决。
- 先定位：查看 Docker 容器日志确认 OOMKilled 状态或 Python 内存报错。
- 先做：调整 docker-compose 内存限制并将大文本存入知识库而非变量。
- 再验证：监控容器内存使用率并确保工作流运行不再中断。
快速处理思路
无法通过单一命令修复，需按以下顺序操作：检查部署配置内存上限，修改工作流避免全量加载文本，启用分片处理逻辑。
为什么会这样
根本原因是工作流变量在内存中完整加载大文本且超出容器限制。Dify 后端服务运行在 Docker 容器中，默认内存限制可能较低，工作流节点（如代码节点或 LLM 节点）若直接接收长文本变量，会将内容全部载入进程内存。若文本长度超过剩余可用内存，触发 OOM 机制导致进程被杀。
分步处理
步骤 1：确认内存溢出证据
登录服务器执行docker ps找到 Dify 相关容器 ID，使用docker inspect <container_id>查看OOMKilled字段是否为true。若为true，确认是容器内存不足。
步骤 2：调整容器内存限制
编辑部署目录下的docker-compose.yaml文件，在api或worker服务下增加mem_limit配置。例如设置为2g，保存后执行docker compose up -d重启服务。注意不要超过物理机总内存。
步骤 3：优化工作流文本传递
进入 Dify 工作台编辑工作流，避免使用变量直接传递万字以上文本。改用“知识库检索”节点，将大文本预先存入知识库，工作流中仅传递查询关键词或文档 ID。
步骤 4：代码节点分片处理
若必须在代码节点处理，编写 Python 代码实现文本分片。每次只处理固定长度片段，处理完释放变量，避免累积。添加日志输出当前处理片段索引以便追踪。
怎么验证是否生效
执行docker stats命令观察 Dify 容器内存使用率，运行一次含大文本的工作流。若容器未重启且日志无MemoryError或Killed字样，说明优化生效。同时检查工作流运行日志，确认所有节点状态为成功。
常见坑
盲目增加内存限制而不优化工作流逻辑，会导致更大文本再次触发溢出。代码节点中创建大列表或字典未及时删除引用，会导致垃圾回收延迟。知识库检索未设置阈值，可能返回过多片段导致后续 LLM 节点上下文溢出。
常见问题
工作流报错 MemoryError 是容器限制还是代码问题？
两者都可能，先看 Docker 是否 OOMKilled。若 Docker 状态正常但应用日志报 MemoryError，通常是 Python 代码逻辑持有过多对象未释放。
知识库检索能完全替代变量传递吗？
不能完全替代，但适合长文档场景。若需精确控制全文本顺序，仍需变量传递，但需配合分片处理逻辑。
增加内存后为什么还是溢出？
可能触发了 LLM 模型的上下文窗口限制而非内存限制。检查报错信息是否包含 token 超限关键词，若是则需减少输入文本长度。