豆破苍琼

摘要： 针对Dify本地环境中忘记密码的问题，建议优先使用内置CLI命令flask reset-password进行重置，而非直接修改数据库。该命令会更新密码哈希和salt值，并清除登录错误限制。在Docker环境下，执行路径为docker compose exec api flask reset-password，支持交互式或参数化输入（需满足8位字母+数字的密码规则）。此方案比页面重置更可靠，尤其适用于未配置邮件服务的本地环境。执行后数据库的password、password_salt字段会被安全更新，

本文明确 Dify 学习目标：从操作到落地 AI 产品，梳理 10 大递进方向，含产品地图、模型、RAG、Workflow、Agent、集成、调试等，区分 Dify/Coze/n8n 定位，给出学习顺序与三阶段项目，掌握后可独立设计交付可落地 AI 应用。

本文提供了Dify本地运行的两种方式：Docker Compose快速启动和源码开发模式。Docker方式适合快速验证环境，一键启动所有服务（前端、后端、数据库等）；源码模式适合二次开发，需分别启动中间件容器和本地前后端服务。文章详细说明了两种方式的前置条件、启动步骤和常见问题排查方法，建议先使用Docker验证环境，再切换到源码模式进行开发调试。关键点在于理解Dify是由多个协作服务组成的系统，而非单一应用。

Dify Workflow是一个基于队列和事件驱动的图执行引擎，而非简单的顺序执行器。其核心执行闭环包括Graph（结构）、GraphRuntimeState（共享运行态）、GraphEngine（总调度）、Worker（节点执行）、Dispatcher+EventHandler（事件推进）和CommandProcessor（外部控制）。模块采用分层设计，入口通过WorkflowEntry装配引擎，Graph负责图结构表示，GraphRuntimeState管理运行时状态，节点通过事件系统异步推进。外部控制

《Dify请求处理链路分析》摘要： 本文系统剖析了Dify系统的请求处理主链路。首先指出Dify采用多入口分流架构，通过不同API前缀(/console/api、/api、/v1等)将请求分类到控制台、Web应用和开放API等不同业务场景。前端通过统一封装层实现请求分流，后端则通过Flask蓝图机制实现路由分发。控制器层承担参数校验、鉴权和上下文注入等重要职责，服务层负责业务编排，协调数据库、AI模型、工作流引擎等核心组件。文章详细分析了控制台API、Web API和Service API三类主入口的特点，

Dify是一个面向LLM应用开发的开源平台，集成了模型接入、应用编排、知识库/RAG、Agent、工作流等核心功能。本文档提供了学习Dify的系统方法：首先从产品能力、系统运行、业务域等六个层次建立宏观认知；然后按照部署、核心能力分专题、问题驱动等阶段逐步深入。重点推荐先理解工作流引擎、模型运行时和RAG三大核心模块，并通过实践任务反向学习代码结构。学习路径建议从README文档入手，逐步掌握系统架构和关键模块，最终实现定制开发能力。