Dify原生不支持跨应用变量共享，因全局变量功能已废弃且存在安全风险；推荐通过Redis直写读取、复用内置session存储或伪造conversation_id三种替代方案实现。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要在Dify中让变量在不同应用（App）之间共享，比如A应用生成的用户画像ID、B应用需要直接读取并用于推荐模型调用，必须绕过默认隔离机制——Dify原生不支持跨应用的全局变量（Global Variables），所有应用级变量天然作用域锁定在单个App内，硬启“全局变量”开关会导致命名冲突、缓存污染和权限失控。
为什么不能直接启用Global Variables
在Dify控制台开启“全局变量”选项后，系统仅将变量注入当前App的$context，并不会广播到其他App实例；更关键的是，该功能已在2026年8月的v0.14.2版本中被标记为废弃（DEPRECATED），启用后控制台会持续报WARN：“Global variable injection is disabled for security isolation”，且每次工作流执行日志末尾强制追加一行红色提示。强行保留该配置，会在多租户环境下引发变量名覆盖——例如两个App同时定义user_tier，后部署者将静默覆盖前者值，且无审计留痕。
替代方案一：通过Redis直写+跨App读取
方法一适用于已部署Redis且具备网络互通权限的生产环境。
第一步：在App A的工作流末尾添加“HTTP请求”节点，向自建中转API发送POST请求，Body为{"key": "app_a:user_profile_{{sys.user_id}}", "value": {"tier": "vip", "score": 92.5}, "expire": 3600}；该API需实现redis.setex(key, expire, json.dumps(value))。
第二步：在App B的首个节点前插入“HTTP请求”节点，调用同一API的GET接口，传参key=app_a:user_profile_{{sys.user_id}}，响应体直接解析为JSON并写入$context.set("shared_profile", response.body)。
【必须确认Redis key前缀含应用标识，如app_a:或app_b:，否则不同App会互相覆盖】
第三步：在App B后续任意节点中使用{{shared_profile.tier}}引用，无需额外转换——因为HTTP节点返回的JSON已被Dify自动解析为对象。
替代方案二：复用Dify内置session存储做跨App桥接
此法无需新增服务，但要求两个App共用同一套Dify后端（即同实例部署或共享PostgreSQL/Redis会话后端）。
① 在App A中，用“Set Variable”节点设置变量cross_app_payload，值为{"user_id": "{{sys.user_id}}", "profile": {"lang": "zh-CN", "theme": "dark"}}；
② 紧接着添加“Run Python Code”节点，执行以下代码：
r = redis.Redis.from_url(os.getenv("REDIS_URL"))r.setex(f"cross_app_bridge:{sys.user_id}", 1800, json.dumps(inputs.cross_app_payload))
③ 在App B的触发节点后立即插入“Run Python Code”节点，执行：
r = redis.Redis.from_url(os.getenv("REDIS_URL"))bridge_data = r.get(f"cross_app_bridge:{sys.user_id}")$context.set("from_app_a", json.loads(bridge_data) if bridge_data else {})
这一步操作起来很简单，直接把Python代码粘贴进去就行，但注意：若sys.user_id为空（如匿名访客），需提前用条件节点跳过写入，否则Redis key会变成cross_app_bridge:导致全量污染。
替代方案三：用Dify API + conversation_id 伪造跨App上下文
当App A和App B均由同一前端调用，且能控制请求头时，可欺骗Dify认为两次请求属于“同一会话”。
方法1：前端在调用App A后，从响应头X-Conv-ID提取conv_abc123，保存至localStorage；调用App B时，在请求Header中手动添加X-Conv-ID: conv_abc123。
方法2：后端代理层统一生成conversation_id，对App A和App B的请求都透传相同ID，并在Nginx中配置：proxy_set_header X-Conv-ID $cookie_conv_id;，前端首次访问时由后端set-cookie写入。
【Dify仅校验conversation_id格式合法性，不验证其归属App，因此该ID可跨App复用】
App B工作流中即可直接使用{{session.cross_app_flag}}——前提是App A曾在同ID会话中通过“Set Variable”写入该字段。
