Dify本地部署完整教程：从零搭建AI应用开发平台

为什么选择Dify而不是其他AI平台

折腾过LangChain、Flowise这些工具之后，我最终把生产环境切到了Dify。原因很简单——Dify是唯一一个让我不用写代码就能把大模型真正用起来的平台。很多人觉得Dify就是个可视化拖拽工具，这个认知太浅了。Dify真正的价值在于它把RAG、Agent、工作流这三件事做成了开箱即用的基础设施，而不是需要你自己拼装的乐高积木。

我在实际项目中遇到的最典型场景：业务团队想要一个能查公司内部文档的AI助手。用LangChain从零写，光向量数据库选型、分块策略、检索重排这些事就得折腾一周。Dify里配个知识库，上传文档，10分钟出原型。这不是夸张，是我上个月刚做的真实项目时间线。

部署前的环境准备

Dify的部署方式有三种：Docker Compose（推荐）、本地源码运行、云服务。这篇只讲Docker Compose方式，因为这是生产环境最稳的方案。

• 操作系统：Ubuntu 20.04+ 或 CentOS 7+（Windows用户请用WSL2）
• Docker：24.0+ 版本
• Docker Compose：V2版本（docker compose命令，不是老版docker-compose）
• 内存：最低4GB，建议8GB以上（向量数据库很吃内存）
• 磁盘：至少20GB可用空间

一个很多人忽略的坑：Docker的存储驱动必须用overlay2。我之前在一台老服务器上用devicemapper驱动，Dify的Weaviate容器频繁崩溃，排查了两天才定位到这个原因。执行docker info | grep Storage确认一下。

一键部署Dify

先把代码拉下来：

git clone https://github.com/langgenius/dify.git
cd dify/docker

复制环境变量文件：

cp .env.example .env

这里有个关键配置要改——向量数据库的选择。默认用的是Weaviate，但我强烈建议改成pgvector，原因后面讲。修改.env文件：

VECTOR_STORE=pgvector

然后启动所有服务：

docker compose up -d

首次启动会比较慢，镜像总大小约3GB。等所有容器状态变成healthy后，访问http://你的IP/install初始化管理员账号。

我为什么推荐pgvector而不是Weaviate

这个问题值得单独讲，因为我见过太多人在这里踩坑。

对比项	Weaviate	pgvector
内存占用	1-2GB起步	共享PostgreSQL，几乎0额外
运维复杂度	独立服务，需单独备份	随主库一起备份
数据迁移	需要导出导入工具	标准SQL dump
生产稳定性	偶发OOM崩溃	PostgreSQL生态，极其稳定
检索性能（百万级）	略优	完全够用

我的结论：文档量在百万级以下，pgvector各方面都更优。只有当你有超大规模向量检索需求时，Weaviate的性能优势才值得你忍受它额外的运维负担。大多数中小团队，pgvector是更务实的选择。

配置大模型接入

Dify支持的大模型非常多，但实际部署中你主要会用到这几种：

• OpenAI GPT-4：效果最好，但国内直连不稳定，需要配代理
• DeepSeek：中文能力强，价格低，国内直连无障碍
• 豆包/通义千问：国内合规首选，企业场景推荐
• Ollama本地模型：数据安全要求高的场景，零外发

配置方式很简单，进入「设置 → 模型供应商」，填入API Key即可。如果是Ollama，确保Ollama服务在Docker网络内可访问，基础URL填http://host.docker.internal:11434。

我个人的组合方案：DeepSeek做日常对话，GPT-4做复杂推理任务，Ollama跑Qwen2.5做离线备份。在Dify里可以给不同应用配不同模型，这个灵活性是它比很多竞品强的地方。

搭建第一个知识库应用

这是Dify最核心的使用场景，也是最容易被用错的地方。

进入「知识库」页面，点击创建，上传你的文档。Dify支持PDF、Word、TXT、Markdown等格式。上传后需要选择分块策略：

• 自动分块：适合新手，Dify自动判断
• 自定义分块：建议选这个，分块大小设为500-800 token，重叠100 token

分块大小是影响检索质量最关键的参数，没有之一。分块太大，检索不精准；分块太小，上下文丢失。500-800 token是我经过大量测试得出的最优区间，大多数中英文混合文档都适用。

另一个容易忽略的设置：检索模式。Dify提供混合检索（向量+全文）和纯向量检索。务必选混合检索。纯向量检索在处理专有名词、编号这类查询时命中率极低，混合检索能补上这个短板。

知识库建好后，创建一个「聊天助手」应用，关联知识库，选择模型，就能用了。整个流程熟练后5分钟搞定。

工作流：Dify的隐藏杀手锏

很多人只用Dify的知识库功能就停了，这太可惜了。Dify的工作流（Workflow）才是它真正的差异化能力。

举个我实际做过的案例：客户提交工单后，自动用大模型分类工单类型、提取关键信息、查询知识库找解决方案、生成回复草稿、发送到飞书群通知相关负责人。整个流程零人工干预。

工作流的核心节点类型：

• LLM节点：调用大模型处理文本
• 知识检索节点：查询知识库
• 代码节点：运行Python脚本做数据处理
• 条件分支：根据结果走不同路径
• HTTP请求：调用外部API

把这些节点组合起来，你能实现远超简单问答的复杂AI应用。工作流是Dify区别于纯聊天工具的分水岭。

生产环境必做的优化

部署完成只是开始，以下是我踩过坑后总结的必做优化：

• 配置Nginx反向代理+HTTPS：不要让用户直接访问Dify的3000端口，配好SSL证书
• 修改SECRET_KEY：.env里的默认密钥必须换，不然有安全风险
• 开启Redis持久化：默认Redis不做持久化，重启会丢session数据
• 设置日志轮转：Docker日志默认不限制大小，跑久了磁盘会爆
• 配置数据库自动备份：pg_dump定时任务，每天备份一次

日志轮转很多人不知道怎么配，这里给个具体方案。在docker-compose.yml里给所有服务加上：

logging:
  driver: "json-file"
  options:
    max-size: "50m"
    max-file: "3"

常见问题排查

Q：容器启动后API服务502怎么办？
大概率是api容器还没启动完，等1-2分钟再试。如果持续502，检查docker compose logs api看具体报错。

Q：知识库检索结果不准怎么办？
三个排查方向：(1) 分块大小是否合适 (2) 是否用了混合检索 (3) 检索topK参数调大试试，默认3可能不够。

Q：Ollama模型连接不上？
确认Ollama在监听0.0.0.0而不是127.0.0.1。设置环境变量OLLAMA_HOST=0.0.0.0后重启Ollama。

Q：如何升级Dify版本？
git pull拉最新代码后，执行docker compose down && docker compose up -d。数据库会自动迁移，但务必先备份。

总结

Dify是目前开源AI应用平台里最成熟的选择，没有之一。它的优势不在于某个单点功能，而在于把大模型应用开发的全链路——从提示词调试、知识库管理、工作流编排到应用发布——做成了一个连贯的系统。本地部署让你对数据有完全掌控权，这在企业场景下是不可妥协的底线。

如果你正在找一款能真正把大模型用起来的工具，花两小时按这篇教程部署一个Dify试试，比看十篇评测文章都管用。