1. 部署 Dify 前的整体思路与应用场景Dify 这个开源 LLM 应用开发平台我最近在一台 Windows 机器上用 Docker 完整跑通了一次。整个部署过程不能说顺风顺水确实踩了不少 Windows 环境下特有的坑但最后一整套服务正常起来的时候那种终于把环境理顺了的踏实感还是很明显的。如果你正在考虑在本地 Windows 机器上部署 Dify或者只是想自托管一个能快速搭建大模型应用的工具台这篇实战记录可以帮你少走很多弯路。先说说 Dify 是什么。简单来讲它是一个集模型接入、Prompt 编排、RAG 知识库、Agent 工具调用、工作流编排于一体的开源平台。以前你想做一个大模型应用要从模型 API 对接开始写再来处理对话上下文、设计 Prompt、做知识库检索、接外部工具这一套下来没有几个星期根本跑不出像样的原型。Dify 把这些问题全部封装成了可视化的操作界面你只需要接入模型 API在界面上拖拽 配置就能快速发布一个可用的 AI 应用。对于个人开发者、产品原型验证、小团队内部工具来说它的价值非常大。为什么我会选择用 Docker 来部署因为 Dify 本身是一个多组件的系统包含后端 API、异步任务队列、前端页面、数据库、缓存、向量数据库等好几块。如果不借助容器化单是装 PostgreSQL、Redis、Weaviate 这些依赖再把 Python 环境和 Node 环境配齐就能消耗掉大半天。Docker 的好处是官方已经写好了编排文件一条docker compose up就能把整个环境拉起来环境隔离干净卸载也方便。我在选择部署方式时对比过源码部署、Docker Compose 部署和云服务部署三条路线最终还是坚持在 Windows 本地用 Docker因为这样可控性最强我能在自己熟悉的环境里随时改配置、看日志、反复调试。这篇文章的核心就是把我在 Windows Docker Desktop WSL2 环境下部署 Dify 的完整过程记录下来包括环境准备、具体步骤、组件拆解、问题排查以及部署完成后的初始化操作。如果你用的也是 Windows 系统这篇内容基本可以照抄。即便你用的是 Linux 或 macOS大部分步骤和原理也是通用的区别主要在于 Docker 的安装方式和文件路径处理方式。1.1 Dify 解决的是什么问题在真正动手部署之前值得先想清楚一件事你部署 Dify 到底是为了解决什么问题。我自己部署它的目的很明确我需要在本地做几个大模型相关的原型实验包括一个带知识库的问答助手、一个多步骤的工作流应用。如果每个都从零写代码进度会很慢而且大部分代码都是重复的比如对话管理、上下文拼接、历史记录存储、接口封装等等。Dify 把这些通用能力做成了开箱即用的模块我只需要关注业务的 Prompt 设计和工具编排。对于团队场景Dify 还提供了多租户、成员管理、应用发布、API 文档等能力等于把一个 AI 应用的后端底座都搭好了。对于个人开发者最吸引人的是 RAG 知识库功能。你可以把本地文档传上去Dify 会帮你做分片、向量化、检索、召回整个过程不需要自己写 embedding 管道和向量检索逻辑。工作流功能也很有意思它用类似流程图的界面把 LLM 调用、条件判断、代码执行、HTTP 请求等节点串起来能实现比较复杂的业务逻辑。从部署者的角度来说Dify 对硬件的要求不算特别高但也不是一杯茶就能跑起来的轻量应用。它至少需要 4GB 内存推荐 8GB 以上。我自己实际体验下来在 Windows 环境下跑起整套服务空闲时内存占用大概在 3 到 4GB 之间一旦有任务在执行内存占用还会往上涨。所以如果你的机器只有 8GB 总内存跑起来会有点紧张建议至少 16GB。1.2 为什么推荐 Docker 这条部署路线Dify 提供了多种部署方式最简单的是直接使用云服务商的托管版本但前提是你信任第三方平台并且愿意把数据和 API Key 交给对方。自托管的话主要有两条路一条是源码部署一条是 Docker Compose 部署。源码部署意味着你需要自己准备 Python 环境、Node 环境手动安装所有依赖还要分别启动前端和后端服务。这个过程对系统的侵入性很强很容易出现依赖版本冲突。我在之前的项目里被 Python 虚拟环境和 Node 版本折腾过太多次所以这次根本没有考虑源码部署。Docker Compose 则完全不同所有依赖都打包在容器镜像里宿主环境只需要装一个 Docker Desktop 就能搞定。从可维护性的角度来说Docker 部署还有一个非常大的优势升级和回滚方便。Dify 的版本更新比较频繁用 Docker 升级只需要拉新镜像、重启容器如果升级出现问题切回旧镜像就能快速回滚。而源码部署要升级就麻烦多了可能要面对一整个依赖树的迁移。1.3 我最终采用的部署环境我的部署环境是一台 Windows 11 机器内存 16GBCPU 8 核。Docker 用的是 Docker Desktop后端建立在 WSL2 之上。WSL2 是目前 Windows 上运行 Docker 最主流的方式它相比旧版的 Hyper-V 方案启动速度更快和 Windows 文件系统的集成也更好。我选择 WSL2 还有一个原因它是 Linux 内核兼容性最好。Dify 的官方镜像和编排文件都是基于 Linux 容器设计的虽然 Docker Desktop 也能跑 Windows 容器但那不是我们需要的场景。Docker Desktop 默认就是 Linux 容器模式正常情况下你不需要做额外切换。在开始正式部署之前我自己做了一件很重要的事把 Docker 和 Dify 的版本确认清楚。Docker Desktop 版本不要太老Dify 建议使用官方发布的最新稳定版本不要直接拉开发分支。因为我需要这套环境做后续实验稳定性比尝鲜新功能更重要。2. 环境准备Windows 上的 Docker 与 WSL2 调优这一步是整个部署过程中最容易出幺蛾子的地方。很多人在部署 Dify 时遇到的一堆诡异问题其实根源都在 Docker 环境本身没准备好而不是 Dify 的代码有问题。我在这里多花点篇幅把自己踩过的坑和最终验证过的配置完整记录下来。2.1 Docker Desktop 安装与 WSL2 检查如果你的 Windows 是 Windows 10 2004 以上版本或者 Windows 11安装 Docker Desktop 已经非常简单了。直接从 Docker 官网下载安装包一路下一步即可。但有一个前提条件容易被忽略WSL2 必须提前启用。安装 Docker Desktop 时虽然它会提示帮助安装 WSL2但如果系统没有提前更新好相关组件后续跑容器时会出现各种内核错误。我给你的建议是在安装 Docker Desktop 之前先打开一个 PowerShell 窗口执行以下命令检查 WSL 的情况wsl --status wsl --version如果显示 WSL 版本是 2 以上说明 WSL2 已经可用。如果提示没有安装发行版可以先执行wsl --install这条命令会安装最新版本的 WSL 以及一个默认的 Linux 发行版。安装完成后一定要重启系统然后执行wsl --status确认状态正常。这里有个很多人容易踩的坑装好 WSL 之后没有重启Docker Desktop 安装完也提示成功但启动容器时莫名其妙报错其实是因为内核没有加载完成。所以看到需要重启的提示时不要偷懒。Docker Desktop 安装完成之后还有一个容易被忽略的设置项Settings General 里有一个 Use the WSL 2 based engine 选项确保它是勾选状态。Docker Desktop 新版本默认就是这个选项但如果你以前装过老版本可能被切换到了 Hyper-V 模式或者 Windows 容器模式。确认是 WSL2 引擎之后在终端执行docker version docker compose version能看到正常的版本输出说明 Docker 环境就绪了。2.2 内存与资源的提前规划Dify 整套服务对内存的要求是不能忽视的。官方文档说最低 4GB 可用内存但那是针对裸机 Linux 环境的说法。在 Windows 上加了一层 WSL2Docker 引擎本身也有开销实际占用会比裸机高不少。Docker Desktop 默认情况下WSL2 最多只能使用物理内存的 50%这一点如果你的机器内存不够大会非常致命。我第一次部署时机器的总内存是 16GBDocker Desktop 默认限制 WSL2 使用约 8GB。理论上这个数值够 Dify 跑但实际上 Windows 本身、浏览器、IDE 等程序也在抢内存当物理内存不足时WSL2 内运行的容器进程可能会被系统直接杀掉表现出来就是 Docker Desktop 突然卡死容器全部变灰。为了避免这个问题我建议在用户主目录下手动创建.wslconfig文件给 WSL2 设置一个合理的固定内存上限。文件内容大概是这样的[wsl2] memory6GB processors6 swap2GB localhostForwardingtrue这里有几个关键参数需要解释一下。memory是给 WSL2 分配的最大内存6GB 对 Dify 来说比较合适既不会和 Windows 主系统抢内存也足够运行。processors是分配的核心数设置成你物理 CPU 核心数减 2 比较合理留一些给宿主系统。swap是交换空间设置 2GB 作为内存溢出的缓冲。localhostForwarding必须保持为true这样你才能在 Windows 浏览器里通过 localhost 访问容器里 Nginx 映射出来的端口。编辑完.wslconfig之后需要在 PowerShell 里执行wsl --shutdown然后重启 Docker Desktop。这一步很多人会漏掉改完配置不生效以为配置没写对。其实只要你执行了wsl --shutdownWSL2 虚拟机就会被完全停止Docker Desktop 下次启动时会自动加载新的配置。2.3 文件系统路径与项目目录规划Windows 环境下部署 Dify 还有一个非常重要但经常被忽略的点项目代码所在路径。Dify 的 Docker 编排会从本地目录挂载若干配置文件到容器里如果项目路径包含中文字符、空格或者特殊符号容器内部的路径解析就很容易出错。我刚开始图方便把 Dify 代码直接 clone 到了桌面上的一个中文目录里结果 Nginx 容器启动后一直报找不到配置文件的错误排查了很久才发现是路径问题。后来我把项目放在D:\dev\dify下问题立刻消失了。所以这里强烈建议把项目目录放在一个纯英文、无空格、无特殊符号的短路径下比如D:\dev\dify、C:\dify都可以。如果你和我一样习惯用 Git Bash 操作也可以直接在命令行里 clone。这里还有一个版本选择的经验Dify 主分支的更新很频繁有时候会有尚未稳定发布的代码。稳妥的做法是拉取官方发布的最新稳定 tag。在写这篇记录的时候我使用的是 1.x 系列的 release 版本部署流程已经比较成熟。建议用下面的方式拉取指定版本的代码git clone -b 1.1.3 --depth 1 https://github.com/langgenius/dify.git-b参数指定分支或 tag--depth 1表示只拉取最新一层的提交记录避免全量克隆仓库导致的网络等待。如果你不指定版本直接 clone 主分支也能用但可能会遇到一些新引入的小问题。版本号建议去 Dify 官方仓库的 Release 页面查看选择最新的稳定版。3. 实战部署从零到完整启动 Dify环境准备好之后真正的部署过程反而比较直接了。这一节我按照我自己操作的顺序整理每一步都会说明这样做背后的原因以及需要注意的细节。3.1 核心配置 .env 的生成与改法进入项目目录下的docker文件夹里面有一个.env.example文件。Dify 的全部环境配置都靠这个文件驱动我们需要把它复制成.env然后按照自己的情况调整。在 Git Bash 或 WSL 终端中执行cd dify/docker cp .env.example .env复制好之后用 VS Code 打开.env文件。这里有一个 Windows 专属的坑要提醒一下千万不要用系统自带的记事本去编辑记事本保存文件时可能会带上 UTF-8 BOM 头也可能改变换行符格式这些都会导致 Docker Compose 在解析环境变量时出现莫名其妙的错误。用 VS Code 编辑注意保存时选择 UTF-8 without BOM。.env文件里需要重点关注的配置项有几个。第一是SECRET_KEY这是 Flask 应用用来加密 Session 和令牌的密钥。默认的SECRET_KEY是一个占位值直接用会有安全隐患而且如果后续你更换了这个值所有已生成的会话都会失效。建议生成一个足够长的随机串在终端执行openssl rand -hex 32把生成的字符串粘贴到.env的SECRET_KEY后面。如果没有 openssl也可以打开 PowerShell 执行-join ((1..32) | ForEach-Object { {0:x2} -f (Get-Random -Maximum 256) })第二是POSTGRES_PASSWORD这是 PostgreSQL 数据库的管理员密码。默认值同样需要改掉改成一段足够复杂的随机字符串。第三是VECTOR_STORE默认值是weaviate也就是使用 Weaviate 作为向量数据库。如果你暂时只做基础的对话应用不打算马上用知识库功能这个配置保持默认即可。如果你后续打算用别的向量数据库一定在第一次启动之前就要想好因为切换向量数据库类型会影响数据存储的方式中途切换会比较麻烦。还有一个需要注意的地方是端口配置。EXPOSE_NGINX_PORT默认是80也就是说 Dify 启动之后你直接访问http://localhost就能打开前端页面。但 80 端口在 Windows 上非常容易被其他程序占用比如 IIS、某些开发工具、甚至一些游戏平台都会抢 80 端口。建议在正式启动之前先检查一下 80 端口是否被占用netstat -ano | findstr :80如果看到有进程监听 80 端口建议直接在.env里把EXPOSE_NGINX_PORT改成8088或者其他你喜欢的端口。这样做的好处是避免后续端口冲突代价只是访问网址多了一个端口号。我这次部署时就把 Dify 跑在了8088端口上。3.2 启动编排文件与首次检查确认.env配置没有问题之后执行启动命令docker compose up -d这里必须说一下docker compose是新版 Docker 自带的插件式编排命令老版本用的是docker-compose中间有一个连字符。Docker Desktop 新版本已经内置了docker compose插件不需要单独安装。如果你在终端里执行docker compose提示找不到命令那大概率是 Docker Desktop 版本太老建议更新到最新版。up -d中-d参数表示后台运行。第一次执行时Docker 会拉取所有需要的镜像。这一步受网络环境影响比较大如果拉取镜像的速度非常慢或者中途出现超时不用慌这是 Docker Hub 镜像拉取的常见问题通常和网络状况有关。可以多试几次也可以提前在 Docker Desktop 的 Docker Engine 配置里设置可信的registry-mirrors把镜像源指向你所在网络环境中可用且你信任的镜像地址。配置格式大致如下{ registry-mirrors: [https://your-trusted-mirror.example.com] }设置好之后需要重启 Docker Desktop 才能生效。重启后再执行一次docker compose up -d拉取镜像的速度通常会有明显改善。启动完成之后用下面的命令查看容器状态docker compose ps正常情况下你会看到一批处于Up状态的容器包括 nginx、api、worker、db、redis、weaviate、ssrf_proxy 等。看到全部Up之后先别急着打开浏览器等几十秒让 API 服务完成初始化。然后执行docker compose logs -f api观察日志输出如果能看到类似应用启动成功的日志没有报错说明后端服务已经就绪。此时打开浏览器访问刚才配置的地址。如果你没有改端口就直接访问http://localhost如果改了端口就访问http://localhost:8088。第一次访问会跳转到安装页面这代表前面所有部署工作已经成功了。3.3 用 docker compose 常用命令管理运行状态部署成功之后日常管理主要依赖几条 docker compose 命令。查看所有容器状态的命令是docker compose ps查看某个服务的日志用docker compose logs -f api停止所有服务用docker compose down重新启动用docker compose up -d。这里有一个重要的提醒docker compose down只会停止并删除容器不会删除容器对应的数据卷所以你的数据不会丢失。但是如果你手误执行了docker compose down -v那就会连同数据卷一起删除所有数据库里的用户、应用、知识库数据都会清空。这是我特别想强调的一点因为我在实际操作中差一点就在升级 Dify 版本时误删了数据卷。如果你只是想临时停一下服务千万不要带-v参数。4. 背后的技术架构与各组件分工在排错和配置的过程中理解 Dify 的容器架构让你能快速定位问题。很多人遇到服务运行异常时不知道问题出在前端、后端还是数据库一个很重要的原因是他们对这套系统有哪些组件、每个组件是干什么的没有概念。我在这里把默认架构拆开说明。4.1 默认的 8 个核心服务Dify 的 Docker 编排默认会启动以下核心服务组件组件名称实际作用默认映射端口存储说明nginx前端静态资源托管与反向代理80 / 443无apiFlask 后端 API 服务不直接对外开放无workerCelery 异步任务队列服务不对外开放无dbPostgreSQL 关系型数据库127.0.0.1:5432数据卷持久化redis缓存与队列存储127.0.0.1:6379数据卷持久化weaviate向量数据库用于知识库 RAG 检索127.0.0.1:8080数据卷持久化ssrf_proxy出站请求安全代理不对外开放无sandbox代码执行沙箱环境不对外开放无表格里的不对外不是指容器不启动而是说这些端口只暴露在容器内部的虚拟网络中不会映射到 Windows 宿主机上所以你在外面访问不到。从请求链路的角度来看浏览器首先访问的是 nginxnginx 根据路径把请求转发给前端静态资源或者后端 api。api 处理完业务逻辑之后需要读写数据时访问 postgres需要缓存时访问 redis。当你创建知识库并上传文档时api 会把文档分片、向量化之后写入 weaviate。worker 则负责处理耗时任务比如知识库索引构建、批量任务执行等它和监督不直接关联但它的健康状态直接影响后台任务是否完成。4.2 为什么要这样的分工Dify 采用这种前后端分离加独立数据库的架构在应用层来看是合理的。api 和 worker 其实代码同源只是启动入口不一样api 处理同步的 HTTP 请求worker 处理异步的耗时任务。之所以要拆开是因为这两类任务对资源的需求不一样。请求处理是高频低耗的异步任务是低频高耗的拆开后可以独立扩展哪个瓶颈严重就单独增加实例。向量数据库是这个架构里比较关键的一块。我在部署时选择了默认的 weaviate它在 Dify 的默认配置下不需要额外设置鉴权直接由编排文件里的环境变量注入即可。如果你后续要接入已有的知识库数据或者想把向量数据库替换成 Qdrant、Milvus 等需要在.env里修改VECTOR_STORE和相关连接参数。这里我再次强调向量数据库类型最好在部署初期就确定因为一旦知识库数据已经写入切换向量数据库不是简单的配置变更而是一次数据迁移。4.3 数据持久化与备份策略Dify 的数据持久化主要是靠 Docker 数据卷来完成的。PostgreSQL 的数据、Redis 的数据、Weaviate 的向量数据都会被挂载到 Docker 的 volume 中。这些数据卷存放在 WSL2 的虚拟磁盘里并不在 Windows 文件系统里直接可见。这样做的好处是容器重建时数据依然保留坏处是如果你想手动备份数据不能简单复制文件需要用 Docker 提供的方式。备份.env文件对我来说是更重要的习惯。这个文件里存着数据库密码、SECRET_KEY、向量数据库配置等关键信息。一旦文件丢失或者误修改恢复会非常麻烦。在部署完成之后我做的第一件事就是把.env复制一份到单独的位置标注好版本号。这样的备份策略虽然很简单但能让你在后续升级时心里有底。如果你确实需要备份数据库比较推荐的方式是在容器层面操作。可以进入数据库容器使用 PostgreSQL 的备份工具导出数据也可以直接备份 Docker volume 目录。但对于个人使用场景最核心的数据其实是三块用户账号、应用流配置、知识库数据。只要你不执行docker compose down -v这些数据默认就不会丢。所以我不建议平时做太复杂的备份操作定时备份.env和数据库导出文件就足够了。5. 常见问题排查与避坑心得这一部分是我最想写的内容。前面说了很顺利的流程实际部署过程中一定会碰到各种意外。我把自己实际遇到的七个典型问题整理成了速查表然后挑几个重点展开说明。这些问题很多都不是 Dify 本身的问题而是 Windows Docker 组合下的环境问题。5.1 典型问题速查表问题现象可能原因解决办法容器启动后立刻退出端口被占用或配置项错误检查日志修改端口配置API 容器反复重启日志显示数据库连接失败PostgreSQL 还没就绪等待数据库初始化或查看 db 日志浏览器访问打不开页面nginx 启动失败或端口映射不对检查 nginx 日志确认EXPOSE_NGINX_PORTDocker Desktop 突然卡死容器全停WSL2 内存不足配置.wslconfig限制内存重启 WSL2镜像拉取非常慢或超时网络波动或镜像源不稳定配置可信 registry mirror多试几次第一次注册提示失败SECRET_KEY 为空或数据库状态异常检查.env重启调优后的容器修改.env后不生效没有执行docker compose down docker compose up -d重启全部容器5.2 端口冲突的详细处理经验端口冲突是我这次部署遇到的第一个真正让我卡住的问题。容器第一次启动时nginx 一直处于重启状态用docker compose ps看到的状态是Restarting。当时我不明白为什么后来查看日志才发现端口冲突。在 Windows 上80 端口被占用的概率很高。我遇到的情况是有个系统服务占用了 80。解决办法很简单修改.env里的EXPOSE_NGINX_PORT把宿主机端口改为 8088。注意这里有个细节你只需要改宿主机侧的映射端口不需要改容器内部的端口。容器内部 Dify 的 nginx 仍然监听 80Compose 会自动完成端口映射。改完端口之后一定要重新执行docker compose down docker compose up -d不要在up状态下只通过restart让配置生效因为docker compose restart只会重启容器不会重新读取.env的改动。这是一个我踩过的小坑在这里延伸说明一下.env里任何配置修改都必须先down再up或者执行docker compose up -d --force-recreate否则改动不会生效。5.3 WSL2 内存问题的深度理解WSL2 的内存问题是我部署过程中遇到的最隐蔽的问题。一开始服务可以正常启动但是用了一段时间后Docker Desktop 偶尔会闪退容器状态全部变成灰色。查看 Windows 事件日志后发现是 WSL2 虚拟机被强制终止了。这个问题的本质是内存不足。WSL2 是一个轻量虚拟机它在 Windows 上运行但内存管理又和原生虚拟机不完全一样。当你机器总内存不够时Windows 会优先保证桌面程序的运行WSL2 进程可能被压缩甚至杀掉。Dify 的服务本身需要约 4GB 内存再加上 Docker 引擎的基础开销和 WSL2 自身占用如果你的机器只有 8GB 内存确实会很吃力。我最终通过配置.wslconfig解决这个问题在前面环境准备部分已经写过了。这里再补充一个排查技巧如果你怀疑内存问题在 PowerShell 里执行wsl --shutdown然后重新启动 Docker Desktop如果全部容器恢复正常基本可以确定是 WSL2 的偶发性崩溃。后续通过限制 WSL2 内存至合理范围并给 Windows 留足内存问题就解决了。5.4 API 容器反复重启的问题API 容器反复重启是另一个高频问题。正常情况下docker compose up -d之后所有容器应该很快都变成Up状态。但如果你发现 API 容器一直在Restarting最常见的场景是数据库还没有完全初始化完成。第一次启动 Dify 时PostgreSQL 容器需要初始化数据目录这个过程可能需要几十秒甚至更久。API 容器在启动时会尝试连接数据库如果连接失败Dify 的启动逻辑会重试但如果没有健康检查机制或者容器配置不同可能一直重启。遇到这种情况我的建议是查看数据库容器的日志docker compose logs -f db如果数据库日志显示正在初始化或已经完成你可以等一小会儿再执行docker compose up -d --force-recreate强制重建容器让 API 重新尝试连接数据库。在正常网络下这个过程应该很快完成。如果你修改过.env里的数据库相关内容也要确认字符串里没有特殊字符导致的解析问题。比如密码中如果包含#或空格在某些解析规则下会被截断。如果出现这种情况建议换一串简单的强密码。5.5 文件路径与挂载相关的隐形问题Windows 路径导致的挂载问题不常见但一旦遇到非常难排查。Dify 的 nginx 容器启动时会从项目目录挂载几个配置文件。如果项目路径中出现空格Docker Compose 解析路径时可能会把路径截断导致容器内找不到配置。我遇到过一次诡异的情况Dify 部署在一个包含空格和中文的目录下nginx 容器启动时提示找不到默认站点配置。当时我满脑子都在检查语法和网络完全没想到路径问题。后来把目录改到纯英文短路径下一切恢复正常。所以我把这条放在第一个阶段最容易踩的坑里希望你能在开始阶段就避免它。如果你已经遇到这个类型的问题快速判断的方法是在项目目录执行docker compose config它会解析并输出最终的编排配置。仔细看 volume 挂载部分的路径如果路径被截断或者包含异常字符你就能看到。这个命令是排查配置类问题的利器。6. 初始化配置与后续使用建议服务跑起来只是开始Dify 还需要完成初始化设置才能使用。上一节的内容能帮你把环境稳定下来这一节主要讲部署完成后要做的几件事以及我实际使用下来的一些心得。6.1 第一次访问与管理员账号创建第一次打开 Dify 地址时页面会跳转到安装引导界面。你需要设置管理员邮箱与密码。这里有一点非常关键Dify 的注册逻辑和普通网站不一样它默认只允许通过这个安装页面注册管理员之后在登录页面注册的账号都默认是普通成员需要管理员在后台审核通过。我之前遇到过有朋友部署完 Dify从登录页面注册了一个账号结果发现没有应用创建权限一度以为平台出了问题。实际上是应该先到/install页面创建管理员再以管理员身份登录之后在成员管理里审核成员或创建普通用户。管理员账号创建成功之后登录进去的第一件事应该是查看平台设置。在设置里可以配置站点基本信息、界面语言、模型供应商等。界面语言支持简体中文这一点对不习惯英文界面的用户很友好。6.2 接入大模型 API Key 的配置要点Dify 本身不内置模型你需要接入大模型提供商的 API。在平台界面的设置里的模型供应商模块中可以看到各种模型供应商的入口。配置的关键在于选择合适的模型类型和填写正确的 API Key。以 OpenAI 为例在模型供应商配置页输入对应的 API Key选择模型名称比如 ChatGPT 系列模型点击保存后模型会在平台上生效。Dify 支持同时接入多家供应商并在应用中切换模型这一点非常方便。除了 OpenAIDify 也能接入 Ansible 系列的模型、Azure OpenAI 等很多来源。你在实际选择时根据自己的 API 类型来配置即可。这里有几个实战经验值得分享。第一API Key 一定不要在多个地方混用如果同一个 Key 在多个项目中使用一旦在某个地方泄露影响面会很大。建议在模型供应商的后台管理界面申请独立的 Key。第二Dify 也支持配置本地模型服务接入如果你内网环境中有部署好的开源模型服务只要接口符合 Dify 支持的格式也能直接接入。第三接入模型之后最好先在聊天调试界面做一个简单的测试确认模型的连通性和响应速度都正常再进行应用开发。这能帮你把模型配置问题和应用编排问题区分开。6.3 创建第一个实际应用的完整流程完成管理员初始化并接入模型之后你就可以正式在 Dify 里创建第一个应用了。从首页点击创建空白应用选择应用类型比如聊天助手或工作流。聊天助手适合做对话类应用工作流适合做复杂的自动化流程。我个人的建议是第一次尝试选择聊天助手这样你可以最快看到效果。进入应用编辑界面后你会看到左边是模型选择区中间是 Prompt 编排区右边是对话调试区。先确认模型已经选对然后在 Prompt 编排区输入系统 Prompt定义你的应用角色和回答规则。右侧对话框里输入一条测试消息点击发送如果模型配置正确应该马上能看到回复。这个流程走通后一个最简单的 AI 应用就完成了。如果你想更进一步试试 RAG 知识库需要先创建一个知识库上传文档Dify 会自动进行分片和向量化处理。处理完成之后再回到应用设置里把知识库关联到应用中。这样用户在提问时系统会先从知识库检索相关内容再把它拼接到 Prompt 里交给模型生成回答。整个流程全部在界面上完成不需要写代码这也是 Dify 最方便的地方之一。6.4 个人使用体验与后续优化方向整套部署和初步使用下来我的整体感受是Dify 确实是一个可以拿来就用的平台但你在部署阶段还是要对底层环境有足够的理解否则碰到问题容易抓瞎。我这次在 Windows 上部署最大的收获是学会了如何排查 Docker 容器的日志和如何调整 WSL2 的资源限制。这些能力不只是对 Dify 有用任何基于 Docker 部署的工具在 Windows 上遇到问题时排查思路都是相通的。后续如果我想把 Dify 用得更好有几个方向可以优化。一是把模型请求的使用量记录下来通过数据反馈调整 Prompt 和应用逻辑二是尽快配置知识库把内部文档和项目资料索引起来让应用真正开始积累业务价值三是考虑数据备份的自动化方案虽然当前数据量小但等真正的业务跑起来之后备份的重要性会指数级上升。对于要在 Windows 上长期跑 Dify 的用户我还有一条非常实际的经验不要轻易在 Docker Desktop 上进行大版本升级升级前先记录当前容器的运行状态和镜像版本。Docker Desktop 的大版本更新有时候会改变 WSL2 内核或网络栈的行为可能导致已经稳定的 Dify 环境出现新的问题。如果一定要升级选择业务低谷期操作并确保.env和关键数据已经有妥善备份。