Dify 代码节点为什么有结果却接不下去：输入、输出契约与沙箱排错

从一进一出的最小转换开始 如果目标是把多条记录整理成下一节点需要的结构，先选一条短输入，只返回一个明确字段。确认后续节点能读取这个字段，再逐步增加数组、嵌套对象或计算。一次把全部逻辑放进去，往往会把返回契约问题与算法问题混在一起。 声明与返回要一致 官方文档要求先配置输入变量，并让函数返回包含已声明输出变量的字典或对象。Python 与 JavaScript 都支持常见数据处理，但工作流消费的是结构化返回值。打印日志用于观察，并不能替代输出声明；变量名称和实际返回键也应逐项对应。 一个能检查声明与返回的最小函数 在测试节点中声明字符串输入 text 和字符串输出 normalized，把上游的一条短文本映射到 text。Python 示例可以写成一行： def main(text: str) -> dict: return {"normalized": text.strip()} 给它自拟输入“ A B ”，预期 normalized 为“A B”：首尾空格去掉，中间空格保留。在下一节点通过变量选择器读取 normalized，再用纯空格输入检查输出是否为空字符串。这个例子只验证字符串转换与返回契约，不依赖第三方包。 随后故意将返回键改成 result，而输出声明仍为 normalized，观察节点是否在输出验证阶段报错。恢复后再把上游映射断开，区分“输入未传入”和“函数内部计算错误”。调试时这两种失败的修复位置不同，继续在 print 中输出正确结果并不会补上缺失的输出变量。 不要把本地环境当成沙箱环境 自托管 Dify 的代码节点依赖独立 sandbox 服务。开发机上已安装的包，并不据此自动存在于该服务中。官方提醒查看当前安装中的可用依赖列表。若本地运行正常而节点报导入错误，应先核对沙箱版本、包与运行配置，再修改业务逻辑。 输出也会被验证 API 侧存在字符串长度、数字范围、精度、嵌套深度和数组大小等限制。所核对文档分别列出 CODE_* 配置项，并指出这些限制与沙箱执行配置属于不同位置。因此“函数执行完毕”与“返回结果被接口接受”是两次不同检查。 编辑建议先缩小输入，看短结果是否能够通过；再逐步扩大数组与嵌套层数，定位触发限制的维度。不要直接全面放大限制，因为真正的问题可能是一次返回了不需要的大量内容。 重试不能修复相同的错误输入 节点支持自动重试与失败回退。对于缺少必需字段、除零或返回键拼错，同一输入重复执行通常仍会失败。应先让输入检查给出明确原因，再决定是否进入替代分支。只有识别为可能恢复的故障时，重试才有清晰目的。 较复杂的汇总还需要先决定空输入的业务含义。例如求平均值时，空数组的平均值不是零；可以在前置分支处理“没有记录”，或者使用你明确声明的结果状态。若直接 sum(data) / len(data)，空数组会除零，重试同一份输入仍然失败。 大结果失败时也先做减量对照：保留相同结构但减少记录数，或保留记录数但减少每项文本。前者恢复说明数量可能相关，后者恢复则提示单项或总输出体积值得继续查。把定位结果对应到 API 侧的 CODE_* 限制，而不是只调整 sandbox 的执行时间。 保留一组边界样例 至少测试空数组、缺字段、数值边界和预期最大数据量。检查返回结构是否稳定、后续节点是否仍能读取，以及失败时是否暴露可定位的原因。若需要外部依赖或网络，分别核对实际沙箱环境与对应版本配置；本地装包成功不能证明节点里可用。

本篇涉及的工具1

Dify

用代码转换工作流数据并返回结构化输出

适合场景

在 Dify 中使用 Python 或 JavaScript 转换数据、计算字段的开发者。

需要留意

变量声明、API 输出限制与 sandbox 依赖环境需分别核对。

了解项目 访问官网