★ FEATURED ARTICLE 1. 先把方案想清楚为什么是 WSL2 加 Docker在 Windows 上折腾 Dify 本地部署这件事我前前后后重装过四次环境踩的坑从 BIOS 里虚拟化没开到容器起来了却打不开页面基本集齐了。所以这篇不讲虚的直接把我最后跑通的那套流程、参数和排查经验摊开写。核心结论先摆出来Windows 本地部署 Dify最省心的路径是 WSL2 打底、Docker Desktop 承接容器、知识库跑在本地卷上三者串起来之后你得到的是一套数据不出本机、随时能推到重来、还能顺手接本地模型的完整环境。很多人第一次听到这套组合会皱眉觉得绕。为什么不能直接装个 Windows 版 Docker为什么不能在 Windows 里跑 Python 起服务我最初也是这么想的结果在依赖编译上耗掉整整两个晚上。Dify 的服务栈不轻后端 API、前端 Web、后台 Worker、PostgreSQL、Redis、向量数据库、Nginx 反向代理六七个组件互相依赖。在 Windows 原生环境里一个个装光 Python 包和数据库驱动就够你喝一壶更别说后端有些组件在 Windows 下的行为差异。而 WSL2 给的是一个货真价实的 Linux 内核Docker 镜像里的构建脚本原样就能跑这是最大的价值。1.1 三个绕不开的现实问题第一个问题是数据归属。知识库里的文档、切片、向量、对话记录全是你自己的东西。放到别人的托管服务上功能是现成的但你对数据落地的控制力就弱了一截。本地部署的核心收益就在这——所有文件都躺在你自己硬盘的 volumes 目录里备份、迁移、删除都由你说了算。第二个问题是调试可见性。你要调分段策略、要看索引任务卡在哪一步、要改检索参数本地环境能直接翻日志、能进容器看文件、能改代码重启。这种掀开盖子看的能力是学习和二次开发的必需品。第三个问题是成本和频次。做实验的时候你会反复建知识库、反复换模型、反复测试召回效果这些都是高频低价值的操作。本地跑你怎么折腾都不心疼接云端接口的话每次试验都在消耗额度心态会变形。这套方案适合谁我总结下来是三类人需要把内部文档变成可问答助手的团队、想做 RAG检索增强生成实验但不想被计费和网络波动打断的开发者、以及想搞明白知识库到底是怎么把文档变成答案的这件事的学习者。如果你只是想快速体验一下对话界面那本地部署的投入产出比并不高直接看在线演示更划算。1.2 硬件与系统底线我把实测下来的配置要求整理成表避免你装到一半才发现内存不够项目最低能用我的建议说明操作系统Windows 10 21H2 或 Windows 11Windows 11 较新版本版本太老时 WSL2 组件缺失升级成本高内存8 GB16 GB 及以上知识库索引时内存峰值会明显抬高CPU4 核6 核以上需要支持虚拟化并在 BIOS 中开启磁盘40 GB 空闲100 GB 固态镜像、模型文件、向量数据都吃空间显卡不需要有独立显卡更好只影响本地大模型推理速度不影响 Dify 本体这里有个特别容易忽略的点WSL2 是一个虚拟机它默认会吃掉宿主一半的内存而且不会主动归还。8 GB 机器如果不做资源限制Windows 本身加上浏览器再被 WSL2 拿走一半容器一启动就直接内存告急。后面我会专门讲怎么用.wslconfig给这块资源上笼头。1.3 部署形态怎么选Dify 在本地落地实际有两条路容器编排和源码直跑。容器编排就是官方仓库里那套docker-compose.yaml一条命令把七八个服务全拉起来。源码直跑需要你自己装 Python 3.11、Node 18、PostgreSQL、Redis再分别启动前后端和 Worker。我两条都试过结论很明确除非你要改源码做二次开发否则一律走容器。原因不复杂组件之间的版本兼容、环境变量传递、进程守护容器方案已经有人替你趟过一遍了你只需要改配置。源码直跑唯一的好处是调试方便改一行代码自动热重载。但这种便利只有在你真的动源码时才成立如果只是接模型、建知识库、调参数容器完全够用而且挂了以后一条docker compose down再up -d就能复原心态稳得多。至于生产环境要不要用这套本地方案我的观点是本地部署定位在开发、验证、个人和小组使用真上量了数据库密码、备份策略、反向代理的 HTTPS、日志收集这些都得重新设计那时候建议上正式的服务器编排别硬扛在个人电脑上。2. WSL2 环境落地从启用功能到资源调优这一节是整个流程里最容易卡住的地方我见过太多人卡在第一步。把顺序理清楚很关键先确认 BIOS 里虚拟化开了再开系统功能最后装发行版。顺序错了会出现各种莫名其妙的报错。2.1 启用虚拟化并安装发行版第一步进任务管理器看性能标签页里 CPU 那一栏有没有虚拟化已启用。如果是已禁用关机进 BIOS把 Intel 平台的 VT-x 或 AMD 平台的 SVM 打开。这一步不做后面所有环节都会连环失败。确认之后用管理员权限打开 PowerShell一条命令搞定安装wsl --install -d Ubuntu-22.04这条命令会自动帮你开启适用于 Linux 的 Windows 子系统和虚拟机平台两个可选功能下载内核更新包然后装上指定的发行版。装完需要重启一次。如果你之前开过 WSL 但版本混乱先跑下面这几条清理一下wsl --update wsl --set-default-version 2 wsl --list --verbose--list --verbose会列出所有发行版和它们的 WSL 版本号。必须确认版本号是 2如果是 1手动转过来wsl --set-version Ubuntu-22.04 2转换过程可能要几分钟中间会显示进度。我有一次转了二十分钟没动静后来发现是这个发行版里装了一堆东西转换时要重打包文件系统。这种情况耐心等等或者干脆导出数据重装一个干净的发行版。第一次进入 Ubuntu 会要求设置用户名和密码。这个密码是 sudo 用的输的时候屏幕上不显示字符不是键盘坏了正常盲输回车就行。2.2 .wslconfig 参数逐个调这一步决定了你的机器会不会在跑起容器之后整体卡死。WSL2 的默认行为是最多占用物理内存的 50%虚拟处理器数量等于逻辑核心数而且内存用出去之后不轻易还给 Windows。对于本地部署这种容器常驻的场景这个默认策略很危险。配置文件放在你的 Windows 用户目录下文件名就叫.wslconfig没有扩展名。用记事本或者 VS Code 新建就行[wsl2] memory8GB processors4 swap4GB swapFileD:\\wsl\\swap.vhdx localhostForwardingtrue [experimental] autoMemoryReclaimgradual sparseVhdtrue几个参数我一个一个说为什么这么定memory8GB这是给 WSL2 虚拟机的内存上限不是预留。16 GB 物理内存的机器给 8 GB 是比较均衡的值剩下的留给 Windows 和浏览器。如果你是 32 GB给到 12 GB 到 16 GB 都行。给太小PostgreSQL 和 Worker 抢内存索引任务会莫名失败。processors4容器并行跑几个服务4 个虚拟核心够用。给太多反而会和宿主机抢 CPU导致你在 Windows 里操作时明显卡顿。swap4GB交换分区防止内存峰值直接 OOM 杀掉进程。注意这是放在磁盘上的文件读写慢只是兜底不是性能手段。swapFile指定 swap 文件位置。默认它在系统盘如果你系统盘空间紧张就指到大盘去。Windows 路径在 ini 里要写双反斜杠。localhostForwardingtrue这个很关键它让 WSL2 里的服务能通过localhost被 Windows 访问。默认就是开的但有些优化工具会把它关掉显式写一遍保险。autoMemoryReclaimgradual让 WSL2 在空闲时逐步把内存还给 Windows。这个属于实验性选项不同版本行为有差异但实测在近两年的版本上效果不错能明显缓解关掉容器后内存还不回来的问题。注意.wslconfig修改后必须执行wsl --shutdown完全关闭 WSL再重新进入才生效。只关终端窗口是不算的虚拟机还在后台跑着。改完配置检查一下是否真的生效进 WSL 里跑free -h nproc看Mem那一行的 total 是不是接近你设的值nproc输出是不是等于你配的处理器数。对不上就回去检查文件位置和拼写。2.3 磁盘位置与空间回收WSL2 发行版默认装在系统盘这个 ext4 虚拟磁盘文件会随着你拉镜像、存模型不断膨胀。真实情况是你删了容器里的文件这个虚拟磁盘文件也不会自动缩小。用久了你会看到系统盘莫名少了几十 GB。有两个应对办法。一是装的时候就迁走wsl --export Ubuntu-22.04 D:\\backup\\ubuntu.tar wsl --unregister Ubuntu-22.04 wsl --import Ubuntu-22.04 D:\\wsl\\ubuntu D:\\backup\\ubuntu.tar --version 2注意--import之后默认用户会变成 root需要改回来# 在 /etc/wsl.conf 里加 [user] default你的用户名二是定期压缩虚拟磁盘。新版 WSL 支持直接把磁盘设为稀疏模式wsl --manage Ubuntu-22.04 --set-sparse true老版本就得走 diskpart 的手动流程先wsl --shutdown然后用 diskpart 选中 vhdx 文件执行compact vdisk。这一步我建议一个月做一次尤其是你频繁拉取和删除镜像的话。2.4 Docker 侧的准备Docker Desktop 装好之后第一件事是进设置里确认两处第一处General 里勾选Use the WSL 2 based engine。这是必须的否则它会在 Windows 上另起一套虚拟机和你的 WSL2 环境割裂localhost也不通。第二处Resources 里的 WSL Integration把你装的发行版开关打开。这样在 WSL 终端里可以直接敲docker命令不用切窗口。镜像拉取慢是常见问题配一个镜像加速地址能省不少时间。在 Docker Desktop 的 Docker Engine 设置里改 JSON{ registry-mirrors: [https://你的加速地址], max-concurrent-downloads: 4 }加速地址从云服务商的控制台获取填进去重启 Docker 生效。max-concurrent-downloads调到 4 能让多个镜像层并行拉对首次部署提升明显。验证一下环境是否真的打通docker version docker run --rm hello-world第二条命令能正常输出欢迎信息说明镜像拉取、容器运行、WSL 集成三件事都通了。这一步过了后面才有得谈。3. 拉起 Dify 服务配置项逐条过一遍环境打通之后真正的部署其实很快官方编排文件已经把大部分工作做完了。但有几个配置项必须改改了才能跑得顺没改就会在某个意想不到的地方卡住。3.1 代码获取与目录结构从官方仓库把代码拉下来进到 docker 目录git clone 官方仓库地址 dify cd dify/docker cp .env.example .env拉下来之后先别急着启动花两分钟看一眼目录结构心里有个数dify/docker/ ├── docker-compose.yaml 主编排文件 ├── .env.example 环境变量模板 ├── volumes/ 所有持久化数据落在这里 │ ├── app/storage/ 上传的原始文档 │ ├── db/data/ PostgreSQL 数据 │ ├── redis/data/ Redis 持久化 │ ├── weaviate/ 向量数据 │ └── nginx/ 访问日志 └── ssrf_proxy/ 出站请求处理配置volumes这个目录是你的命根子。知识库文档、切片结果、向量数据、对话历史全在里面备份就是打包这个目录。反过来你想彻底重来一遍把这几个子目录删掉再启动就是全新环境。3.2 .env 里真正要改的那几行.env.example里几百行配置大部分保持默认就行。但下面这几项我建议逐条确认密钥。SECRET_KEY必须换成随机值别用模板里的默认串openssl rand -base64 42把输出贴到.env里。这个密钥用于会话签名换掉之后所有旧登录态失效属于正常现象。数据库密码。DB_PASSWORD默认值太弱而且默认值里带特殊字符的话在某些 shell 环境下会解析出错。我的建议是设一个只含字母和数字的长密码避开这个问题DB_USERNAMEpostgres DB_PASSWORD换成你自己的长密码 DB_DATABASEdify密码改了之后如果你之前已经启动过并生成了数据卷PostgreSQL 里的密码不会跟着变会连不上。这时候要么改回旧密码要么把volumes/db/data删掉重建。这是新手最常踩的坑之一。端口。默认通过 Nginx 暴露 80 端口。Windows 上 80 端口经常被系统服务或者别的软件占着启动时会报端口冲突。直接改掉EXPOSE_NGINX_PORT8080这样访问地址就变成http://localhost:8080。同理如果 5001 之类端口也被占用对应的EXPOSE_变量一并改。时区。默认是 UTC日志时间会和你本地差几个小时排查问题时很容易看错时间线TZAsia/Shanghai上传大小限制。知识库要传大文档的话默认限制可能不够UPLOAD_FILE_SIZE_LIMIT50单位是 MB。调到 50 到 100 之间比较实用。调太大要小心内存和解析耗时。提示.env里的值不要加引号尤其是密码和密钥。加了引号会被当成值的一部分传进容器表现就是密码校验失败且报错信息完全看不出原因。3.3 启动、自检与初始化管理员配置改完一条命令拉起docker compose up -d第一次执行会拉好几个 GB 的镜像视网络情况要等十几分钟到半小时。这时候别盯着看去泡杯茶。中途如果某层卡住不动按 CtrlC 中断再重跑Docker 会续传已完成的层。起来之后先看状态docker compose ps正常的话能看到 api、worker、web、db、redis、weaviate、nginx、sandbox 这些服务状态是 running 或者 healthy。有几个服务会显示healthy是需要等待的PostgreSQL 和 Redis 有健康检查刚启动那几十秒显示starting属于正常。紧接着看日志特别是 api 这个服务docker compose logs -f api看到数据库连接成功的日志、迁移完成的日志、服务监听的日志就说明后端起来了。如果一直在刷连接数据库失败的报错八成是密码问题或者 db 容器没起稳先用docker compose logs db看数据库侧。服务齐了之后浏览器打开http://localhost:8080。首次访问会自动跳到初始化页面要求你设置管理员邮箱和密码。这个账号是超级管理员密码设复杂点虽然本地环境风险低但养成习惯没坏处。设置完会自动登录进入控制台。3.4 端口与访问方式有一个细节值得单独说WSL2 里的服务Windows 浏览器用 localhost 就能访问靠的是端口转发。这个机制大部分时候靠谱但偶尔会失灵表现是容器明明在跑浏览器却连接被拒绝。遇到这种情况按这个顺序排查先在 WSL 里用curl -I http://localhost:8080确认服务本身是通的通的话就在 Windows 侧确认.wslconfig里localhostForwarding是 true还不行就wsl --shutdown重启一次端口转发会重建。另一种情况是局域网里别的设备要访问。这个默认是不通的需要额外做端口转发配置把 Windows 的端口映射进 WSL2 的地址。局域网共享的配置涉及网络规则我一般不建议在个人机器上开真要多人用还是放到专门的服务器上更合适。4. 模型接入本地跑还是调接口Dify 本身不带模型它是个编排壳子。真正让它会说话的是你接进去的大模型和向量模型。这一步的选择直接决定了后面知识库的效果和你的硬件压力。4.1 两条路线的取舍接入方式就两种本地跑和调外部接口。本地跑的好处是数据完全闭环不依赖外部网络成本是一次性的。坏处是对硬件有要求7B 级别的模型在纯 CPU 上推理会慢到让你怀疑人生最好有能用的显卡。而且模型文件动辄几个 GB磁盘要留够。调外部接口的好处是效果上限高、响应快、不占本地资源模型升级也不用你操心。坏处是数据要发出去且调用有频次和额度限制做实验时容易束手束脚。我的实际做法是两条腿走路聊天和推理用外部接口保证体验做知识库索引必须用的向量模型放本地跑。向量模型参数量小CPU 上跑完全可接受而且索引是批量任务慢一点不影响交互体验。4.2 本地模型接入实操以 Ollama 为例Windows 上直接装客户端就行装完它会常驻在后台。命令行拉两个模型ollama pull qwen2.5:7b ollama pull bge-m3第一个是对话模型第二个是向量模型bge-m3输出 1024 维向量中文效果不错模型体积也不算大。关键的一步在这里Ollama 默认只监听本机回环地址容器里的 Dify 是无法直接访问的。你必须让它监听所有网卡# Windows 上设置系统环境变量 setx OLLAMA_HOST 0.0.0.0:11434设置完必须重启 Ollama 服务才生效。验证方式是在 WSL 里跑curl http://host.docker.internal:11434/api/tags能返回模型列表就说明通了。host.docker.internal这个特殊域名是 Docker Desktop 提供的指向 Windows 宿主机在容器内部也能用。如果你的环境里它解析不了替代方案是查 Windows 的虚拟网卡地址通常形如172.x.x.x直接填 IP。回到 Dify 控制台右上角头像点进去找到模型供应商设置选 Ollama填两个配置模型名称qwen2.5:7b 基础 URLhttp://host.docker.internal:11434向量模型在同一个供应商下再配一条模型名bge-m3类型选 Text Embedding。保存时它会做一个连通性测试通过就说明配置正确。4.3 接入后的连通性验证配完别急着建知识库先做一次最简验证新建一个空白应用类型选聊天助手模型选刚配的那个随便问一句你好。能正常返回说明推理链路通了。如果报超时按这个顺序查先在 WSL 里curl一次/api/tags确认地址可达再确认 Ollama 进程真的在跑最后检查 Windows 防火墙有没有拦掉 11434 端口的入站连接。防火墙上这条规则很多人会漏掉表现是宿主机浏览器能访问 Ollama但容器里访问不到。向量模型的验证稍微麻烦一点它不能直接对话。最快的办法是去知识库页面建一个空库上传一个几百字的小文本文件看索引任务能不能跑完。跑完了状态变成可用就说明向量模型工作正常。5. 知识库搭建从传文档到能答对前面都是铺垫这一节才是真正产生价值的部分。知识库的效果好坏八成取决于分段策略和检索参数模型反而是次要因素。我见过太多次接了大模型但答非所问问题几乎都出在切分上。5.1 分段策略决定成败的第一步文档传进去不是整篇塞给模型而是先切成小块每块单独做向量检索时按块召回。切得好召回的块语义完整切得烂一个答案被劈成两半模型拿到的上下文残缺回答自然驴唇不对马嘴。Dify 里几个关键参数参数默认值我的建议影响分段标识符\n\n按文档类型调整决定在哪里断开最大分段长度500 tokens300 到 600太小丢上下文太大稀释语义分段重叠长度50 tokens50 到 100防止答案被切断预处理规则替换连续空格换行保留默认清理格式噪声分段标识符是最容易被忽视的一项。默认用双换行也就是按自然段切这对结构规整的文档很友好。但如果你传的是技术手册或者表格密集的文档双换行可能到处都是切出来全是碎片。这时候换成单换行或者句号更合适。反过来如果文档是一大段一大段的叙述双换行都很少出现那就得把最大分段长度调小让系统强制切。最大分段长度这块我踩过坑。早期为了省钱把它设到 200结果问答时经常只召回半句话。后来统一调到 500 左右效果明显好转。判断标准很简单切出来的块单独读一遍语义是不是自洽的。你可以在知识库的文档详情里看到实际切分结果这个预览一定要看比任何参数说明都直观。分段重叠是个保险机制让相邻块共享一部分内容防止一个完整句子正好落在切分点上被劈开。50 到 100 tokens 是比较平衡的值设太大索引体积会膨胀检索时召回一堆重复内容。5.2 索引方式与向量模型选择建库时有索引方式的选择高质量和经济两档。高质量走向量化用嵌入模型把每块转成向量存起来检索靠向量相似度经济模式走关键词倒排索引不调模型速度快但语义理解弱。只要你的场景涉及用不同的话问同一个意思就必须选高质量。比如文档里写设备停机后的恢复流程用户问机器停了怎么重新开起来关键词索引很可能匹配不上向量索引能靠语义距离命中。代价是索引时要调向量模型文档多的话耗时会拉长而且向量数据会占不少磁盘。向量模型的选择上中文场景我一般用bge-m3这类多语言模型。它的好处是同时支持稠密和稀疏检索中文语义表达也比较准。有些团队会选更大的模型追求效果但要注意向量维度变高之后向量库的存储和检索开销都会上涨本地机器上不一定划算。这里有个实操细节向量模型一旦选定同一个知识库里就不能混用。因为不同模型产出的向量维度不同混在一起没法算相似度。所以建库之前想清楚别建到一半换模型那只能推倒重来。5.3 检索参数与召回测试库建好、文档索引完成之后别急着做应用先做召回测试。Dify 在知识库里有命中测试功能输入一个问题它会把召回的块和相似度分数列出来。这一步的价值极高。你能直接看到问题命中了哪几块、分数是多少、内容相不相关。如果命中内容明显不对回去改分段如果内容对但分数普遍偏低考虑调检索策略。几个核心参数Top K召回几块。默认 3 到 5 比较合理。调大能提高召回率但会把无关内容也塞进上下文稀释模型的注意力还可能超出上下文长度限制。Score 阈值低于这个分数的块直接丢弃。设太高会漏召回设太低会引入噪声。我一般先看命中测试里的实际分数分布取一个能过滤掉明显不相关内容的中间值0.4 到 0.6 之间比较常见。检索模式向量检索、全文检索、混合检索。混合检索会同时走语义和关键词两条路按权重融合结果对专有名词多的文档效果更好代价是检索耗时略高。Rerank 模型召回之后再精排一次。开启后会把 Top K 的候选块重新打分排序明显提升相关性代价是多一次模型调用。文档量大、问题复杂的场景值得开。我的习惯是先不加 Rerank用混合检索跑一轮命中测试看结果稳不稳。如果 Top 5 里有两三条明显不相关再开 Rerank 试试对比效果。这个对比过程一定要做别凭感觉开。5.4 把知识库挂到应用上知识库配好最后一步是把它接进应用。新建一个聊天助手应用在上下文设置里关联刚才建的知识库然后写提示词。提示词的作用比很多人想的大。知识库负责给料提示词负责定规矩。一个能用的提示词至少要说清三件事你是基于给定资料回答的助手资料里没有的内容不要编造直接说不知道回答要引用依据。我常用的模板结构是这样的你是一个专业助手根据提供的参考资料回答问题。 规则 1. 只依据参考资料作答不要使用资料之外的知识 2. 如果参考资料无法回答直接说资料中未提及 3. 回答时尽量引用原文关键句 参考资料 {{context}} 用户问题 {{query}}这两组花括号变量由系统自动填充不用你手动处理。规则第二条尤其重要不加这条模型在资料不足时会自动脑补这在内部知识库场景里是致命的。关联完做个端到端测试问几个文档里明确有答案的问题看回答准不准再问一个文档里完全没有的问题看它会不会老实说未提及。后者比前者更能反映系统是否可靠。6. 故障排查与长期维护环境跑起来只是开始真正耗时间的是后面遇到的各种异常。我把这几轮折腾中反复出现的问题整理成速查表按现象对照着看能省不少时间。6.1 启动类问题速查现象大概率原因处理方式页面打不开连接被拒绝端口冲突或转发失效改EXPOSE_NGINX_PORT重跑wsl --shutdown502 Bad Gatewayapi 容器没起来docker compose logs api看报错api 反复重启数据库连不上检查密码是否与数据卷里的一致启动卡在拉镜像网络层拉取超时中断后重跑配镜像加速地址初始化页面进不去浏览器缓存了旧跳转清缓存或用无痕窗口容器全部 Up 但无响应内存不足被 OOMdocker stats看内存调大.wslconfig数据库密码不一致这个坑我要重点说。它表现为 api 日志里刷password authentication failed看起来像密码错了其实是你改了.env里的密码但volumes/db/data里存的还是初始化时的旧密码。PostgreSQL 的密码只在数据目录首次初始化时写入之后改环境变量不生效。解决办法有两个改回旧密码或者停服务后删掉volumes/db/data重新初始化。后者会清空所有数据只在环境还没建起来时可用。还有一个隐蔽问题磁盘空间不足导致容器启动失败。Docker 报的错可能五花八门但根因就是没空间写临时文件。跑一次docker system df看镜像、容器、数据卷各占多少再docker system prune -a清理无用镜像。注意这条命令会删掉所有未被使用的镜像拉回来要重新下载用之前想清楚。6.2 知识库与检索类问题文档传上去索引失败先看两个地方文件格式是否被支持、解析器有没有报错。PDF 里如果有大量扫描图像纯文本提取会得到空内容这时候需要 OCR 处理Dify 本身不带这个能力得先把 PDF 转成可提取文本的格式再传。索引任务一直排队不执行多半是 worker 容器出了问题。docker compose logs worker看它是不是在报错重启。worker 负责异步处理索引任务它挂了之后任务会一直卡在排队状态前端只显示索引中不会告诉你后端已经死了。检索结果不相关按这个顺序调整先看切分结果是否语义完整再调 Top K 和阈值然后试混合检索最后加 Rerank。这个顺序是从根因到修饰反过来做往往是白费功夫。我见过有人一上来就开 Rerank结果切分本身就是碎的精排再准也救不回来。回答里出现根据资料显示但内容是错的通常是召回了不相关的块模型照着编。除了调召回提示词里加一条如果资料与问题无关回答未提及能挡住相当一部分这种情况。6.3 资源占用与数据备份长期跑着最需要关注的是三件事磁盘、内存、备份。磁盘方面volumes目录会持续增长尤其是向量数据。定期docker system df -v看一眼各数据卷大小配合前面讲的 vhdx 压缩。如果你的知识库会频繁重建建议每次重建前先确认旧数据确实不要了。内存方面docker stats是最直观的工具能看到每个容器的实时占用。api 和 worker 是内存大户索引大批量文档时 worker 内存会冲得比较高。如果频繁触发 swap说明.wslconfig里的 memory 给少了。备份这件事我的做法很简单停掉服务把整个volumes目录打包再启动。docker compose down tar -czf dify-backup-$(date %Y%m%d).tar.gz volumes/ docker compose up -ddown不会删数据卷只是停容器所以这个操作是安全的。备份文件建议再复制一份到别的磁盘别和源数据放同一个物理盘。恢复就是把压缩包解回去再启动环境原样回来。注意千万不要用docker compose down -v做重启。这个-v参数会连数据卷一起删掉知识库、对话记录、账号配置全部清空且不可恢复。我一开始图省事用过一次代价是重建了一整天。最后分享一个我自己的习惯每次改动.env或者编排文件之前先把整个docker目录复制一份命名为带日期的备份目录。这个操作占不了多少空间但能让你在改崩之后一分钟内回滚。比起对着报错一行行回退配置这个成本低太多了。我个人在实际操作中的体会是本地部署这类多组件系统真正的时间成本不在装而在装完之后不听话。把每次变更都留下可回退的痕迹把关键日志的查看方式记熟比记住任何一条命令都管用。环境是死的人是活的配置改坏了就回滚别硬修这是我折腾这么多轮之后最实在的一条经验。
阅读完成 · 觉得有帮助？
