1. 项目背景"我们 Dify SaaS 版服务了 200 家企业客户。上周一个客户截图说在控制台看到了另一家公司的 App 名称。“这是 SaaS 服务商最怕的事故。Dify 从架构设计之初就考虑了多租户，但"设计支持"≠"部署即安全”——你需要理解三层隔离机制的实现细节和潜在绕过风险。三层隔离：SQL 查询层的 tenant_id 自动注入（每次数据库查询自动加上WHERE tenant_id = current_tenant_id）、Redis Key 层的租户前缀隔离（tenant_a:model_lb:...vstenant_b:model_lb:...）、对象存储层的目录前缀（tenants/{tenant_id}/documents/...）。任何一层有疏漏都可能导致跨租户数据泄露。同时 Dify 实现了 RBAC 权限系统——Owner、Admin、Editor、Member 四角色。理解权限装饰器require_permission()和角色权限矩阵，能让你在不改源码的情况下审计越权操作、为 SaaS 版扩展自定义角色。2. 项目设计——剧本式交锋对话小胖：（看着生产事故报告）“大师！租户 A 的客服 App 回复里出现了租户 B 公司的产品信息。我