第32章：请求生命周期完整源码链路

1. 项目背景前 31 章你一直在"用" Dify——创建 App、写 Prompt、调 API。从本章开始进入高级篇，你要"懂"每一行关键代码。本章是高级篇的"热身"和"导航图"——用一个POST /v1/chat-messages请求串起 Dify 后端的完整 10 步请求生命周期。为什么要理解这 10 步？三个场景：场景一：排查"500 Internal Server Error"。如果你不知道请求经过了 Controller → Service → Core → ModelManager → LLM，你只能逐文件 grep “Error”，大海捞针。但如果你知道链路——先检查 Controller 层的 Pydantic 校验是否通过（通常是 400 而非 500）、再看 Service 层的数据库查询是否超时、再看 Core 层的 Prompt 组装是否有异常——排查效率提升 10 倍。场景二：添加新功能。你需要在"每次 Chat 请求前检查用户是否被封禁"。这个检查应该放在哪里？Controller 的before_request钩子（最外层，拦截所有请求）还是 Service 层的generate()方法（业务编排层）？理解了每一层的职责边界，你才能把代码放在正确的位置。场景三：修改 Workflow 引擎行为。你想让 Workflow 执行时推送进度百分比。你知道要改api/core/workflow/workflow_en