在知识库管理工作中，同步更新的效率直接决定了团队能否及时获取最新文档。Dify 知识库内置了两套自动刷新机制：定时全量同步与差异同步。前者操作简单且覆盖全面，后者则更偏向“按需更新”。不少用户在配置时容易混淆这两者，或不清楚何时该选用哪种方式。下面我们将详细拆解这两种同步模式。

先来看一个真实场景：如果你的文档源每天都会整批替换，或者你希望每次同步后知识库都保持完全干净的状态，那么全量更新是最佳选择。但如果文件变动只是零散的增、删、改，全量重建就显得过于笨重——耗时、消耗资源，而且在同步期间，新查询无法命中刚刚变更的内容。差异同步正是为了解决这一问题而设计的。

配置定时全量更新任务

打开 Dify 控制台，进入「知识库」页面，选择目标知识库，点击右上角的齿轮图标进入设置入口。在设置页面切换到「同步设置」页签，你会看到一个「启用定时同步」的开关。开启后，同步频率提供了三个选项：每天、每周，或者自定义 Cron 表达式。如果选择自定义，则需要输入合法的 Cron 表达式，例如 0 0 * * 1 表示每周一凌晨零点执行一次同步。

关键的一步是——同步模式必须选择「全量同步」。这个模式的操作非常干脆：清空当前知识库中所有已索引的文档片段，然后重新从数据源拉取全部文件，重新进行切片、向量化处理，最后写入向量数据库。听起来是不是有点“伤筋动骨”？没错，因此只有在确实需要全面重置时，才建议使用该模式。

点击「保存设置」后，系统会立即校验 Cron 格式以及数据源的连接状态。这里有一个容易踩的坑：如果数据源未授权或 API 密钥已经失效，保存操作会失败，而且不会弹出任何提示。你需要手动回到「数据源」页签重新绑定一下。

接入支持差异同步的外部数据源

差异同步的关键在于数据源本身需要能够感知变更。目前 Dify 支持三种主流方式。

方法一：Webhook 数据源（内部系统对接首选）
在「数据源」页面点击「添加数据源」，选择 Webhook，然后填写一个用于接收变更通知的 URL。如果你自己搭建了文档变更监听服务，这个 URL 就是该服务的地址。记得启用「增量事件推送」，并勾选「仅推送变更文件列表」。这样，当你的内部系统有文档修改时，Dify 只会收到变更文件的信息，而不是整个文档库。

方法二：对接 Git 仓库（适合 Markdown/Text 类文档）
添加 Git 数据源时，在「高级选项」中开启「启用差异检测」，指定分支（例如 main），再设置文件变更检测路径，比如 docs/**.md。Dify 会基于 Git commit 的 diff，比对前后两次提交的文件哈希值，只拉取新增、修改、删除的文件。如果你的文档是多人协作的 MD 文件，这种方式最为省心。

方法三：S3 兼容存储（MinIO、阿里云 OSS 等）
填写好 Bucket 名称和 Endpoint 后，同步策略需要选择「基于 LastModified 时间戳差异同步」。Dify 每次同步前会列出对象列表，跳过那些 LastModified 早于上次同步时间戳的文件。特别需要注意的是，OSS 必须开启 Bucket 版本控制或生命周期规则，否则如果同名文件被覆盖上传，Dify 可能会漏同步——因为时间戳更新了但文件名没变，容易引发问题。

触发差异化同步的具体操作

绑定好支持差异同步的数据源之后，先执行一次完整的全量同步作为基础。这一步不能省略，因为差异同步是在全量快照的基础上计算差量。

然后在数据源端进行内容更新，例如 Git push 了一个新 commit，或者向 S3 上传了修订后的 PDF，或者通过 Webhook 通知了变更。之后回到 Dify 知识库详情页，点击「同步」按钮右侧的小箭头，在下拉菜单中选择「差异同步」。点击后状态会变为「同步中」，大约等待十几秒，刷新页面，观察「最近同步记录」那一栏，类型显示为「incremental」，并且文档数变动值不为零（比如 +3, -1 就对了）。

这里有一个容易犯的错误：很多人直接点击主「同步」按钮，结果默认执行了全量同步。全量同步不仅耗时长，还会占用向量库的写入带宽，并且同步期间知识库虽然可以查询旧结果，但新查询无法命中刚刚变更的内容。因此，一定要先选择同步类型，再触发操作。