日习一技

应用运行器（App Runner） 是 Dify 应用的核心执行器，负责处理具体的生成逻辑，今天，我们将继续深入应用运行器的内部实现。 应用运行器的概览 让我们以文本生成应用为例，深入 Complet

在前面的文章中，我们深入分析了 Dify 应用生成器的源码实现，从限流策略、流式响应、配置管理、文件上传处理，到追踪调试机制，逐步了解了 Dify 会话处理的完整流程。今天我们将继续深入 Comple

在前面的几篇文章中，我们深入分析了 Dify 应用生成器的源码，包括限流策略、流式响应、配置管理以及上传文件的处理，今天我们将继续深入 CompletionAppGenerator 的 generat

我们之前曾学习过，当模型具备处理图片、文档、音视频的能力时（比如 Gemini 2.5 Pro），在应用的配置页面会多出三个配置开关： 在 “视觉” 右侧有一个设置按钮，还可以进行更细致的配置： 开启

在节前的文章中，我们深入分析了 Dify 会话处理流程的流式处理机制，学习了限流生成器、事件流转换和响应格式化的实现原理。通过分析 rate_limit.generate()、convert_to_e

在昨天的文章中，我们学习了 Dify 会话处理流程的核心服务 AppGenerateService，并通过分析它的 generate() 方法了解了 Dify 如何通过系统级和应用级两层限流策略来保障

在前面的文章中，我们梳理了 Dify 应用的各种会话接口，了解了不同蓝图下五种应用类型的接口实现，以及各自的认证方式和用户类型。如果我们仔细阅读源码就会发现，所有应用的会话接口背后处理逻辑几乎一样：

在前面的文章中，我们学习了 Dify 的代码结构和路由系统，了解了 Dify 是如何通过 Flask Blueprint 和 Flask-RESTX 来组织其复杂的 API 架构的。今天，我们将深入探

我们昨天学习了 Dify 的代码架构和三种启动模式，不过在应用启动过程中，我们并没有看到路由注册的相关代码，这里的关键就在于它模块化的扩展系统。Dify 通过 ext_blueprints 模块注册路