但是又出现另外一个问题了。
net::ERR_NAME_NOT_RESOLVED
Remotely Save一直启动失败，都想放弃了。安装Remotely Sync 后正常了，终于可以愉快的使用了。
期待端到端加密功能的加入
坚果会已经推出了针对obsidian的同步插件，跟这里装的一模一样，不知道是不是楼主的直接被坚果云买走了 
，大家可以直接在第三方插件社区里面搜Nutstore Sync 就可以找到了。不要安装BRAT，直接用。
webdav v2.3.2已经用了很多天，很稳定好用，谢谢。 
发现了一个极小的"逻辑"问题，对使用没任何影响，也没有造成任何错误：
- pc端和移动端插件，“冲突解决策略"均设为"使用最新版本”。
- pc端新建一个"1.md"文档，点击"同步"，上传"1.md"，成功。
- 移动端，点击"同步"，下载"1.md"，成功 。
- 移动端，如果再点击"同步"，会重新上传这个最新的 “1.md”，这里的"逻辑"不对，正确应该提示"没有需要同步的更改"。
- pc端，点击"同步"，会下载 “1.md”。
- 移动端，点击"同步"，才会提示"没有需要同步的更改"。
在使用感受上第4步和第5步是多余的，但这是个小问题，没任何负作用… 
我的猜测：
我没能力阅读插件源代码，虽然表面是第4步有"逻辑"问题，但我猜测是第3步，移动端在下载"1.md"文档时候，改变了文档的“时间戳”或者"某个特征码"，导致和webdav服务器上的最新"1.md"不一致，才会导致第4步重新上传该文档。
@di1jiobs: 测试期间未复现此错误。本插件绝不应执行如您所述的冗余同步。请检查在第二次移动端同步前，您是否对 1.md 进行过修改，或者是否有其他插件在笔记创建后自动修改了笔记内容？
@luove512: 需要澄清的事实是：Nutstore 并未“购买”本插件。两款插件均为开源，且 WebDAV Sync（本插件）实际上是由 Nutstore Sync 演变而来。主要改进包括：
- 重写了大部分内部逻辑（我必须吐槽 Nutstore Sync 的代码堪称“屎山”）。
- 实现了通用性。
- 提升了安全性（使用 Obsidian Keychain 存储凭证，而非将密码明文存储在文件中）。
- 修复了一些关键 Bug。
- 大幅提升了性能（体积缩小 60%，对于没有速率限制的 WebDAV 服务，同步速度比 Nutstore Sync 快 50 倍）。
- 增加了更多功能与选项（例如 Nutstore Sync 目前不支持同步 Obsidian 配置，而本插件支持）。
@Thehone: E2E 加密似乎是许多用户的迫切需求。我认为拖延毫无意义：若一切顺利，v2.4 版本将侧重于稳定性提升和用户体验优化，而 v2.5 版本将包含 E2E 加密功能。未来几周的插件开发进度可能会稍慢，因为我个人目前工作繁忙。感谢理解。
1 个赞
不好意思，我没有改动过1.md，我把其他所有插件关闭，一个个打开测试。
最终发现不是WebDAV Sync问题，是Templater插件的问题（设置打开了"Trigger Templater on new file creation"选项，关闭这个选项就没这个问题），我发帖时候用的是Templater v2.19.0，更新到 v2.19.1，问题依旧。
奇怪的是我查看了1.md的内容，Templater没改动任何内容，经过检查是改变了文档的"修改时间"。 
比如：
在pc端1.md最后修改时间是：21:47分
在移动端，同步，把1.md下载回来，发现最后修改时间是：21:50分 (即同步时间)
1.md有内容的不是空文档，也没给它设置"Templater模板"。
很奇怪，Templater怎么会在文档"下载"成功后，没有改变内容，单独改变它的"修改时间"，我也不用github，不知道怎么向Templater反馈问题。。
老师，这个同步必须要挂梯吗？一直显示“检查连接”
问题解决。
我用deepseek分析了Templater插件的问题，还真找到了，但我不太会编译.ts文件，我直接修改 plugins\templater-obsidian\main.js 这句代码：
await e.overwrite_file_commands(n)
改成
console.log("好像是负作用代码，已删除")
完美解决问题！我看了ai的分析，貌似这行代码并没实际作用，删除后少了这步，速度还快了一些。
否则，每同步一个新文件就执行一下这个方法，反而导致有点卡顿。
deepseek分析如下
事件监听注册 (EventHandler.ts)：
在 EventHandler.ts 的 update_trigger_file_on_creation 函数中，通过以下代码监听了所有文件创建事件：
this.trigger_on_file_creation_event = this.plugin.app.vault.on(
"create",
(file: TAbstractFile) =>
Templater.on_file_creation(
this.templater,
this.plugin.app,
file,
),
);
app.vault.on(“create”) 是 Obsidian 的底层 API，它不仅会在你新建文件时触发，当文件通过同步、复制等方式首次出现在仓库时同样会触发。
文件处理逻辑 (Templater.ts)：
事件触发后，会调用 Templater.on_file_creation 方法。尽管该方法开头有template_folder 过滤逻辑，但对于普通的、内容不为空且不在模板文件夹内的文件，它最终会执行：
// Templater.ts 的 on_file_creation 函数中
await templater.overwrite_file_commands(file);
这个 overwrite_file_commands 方法会解析文件内容中的模板命令，并调用 Obsidian 的 app.vault.modify(file, output_content) API 来写入文件。
问题的直接原因：
这个 app.vault.modify 调用就是修改时间戳的元凶。即使文件内容因未找到模板命令而没有任何实际更改，调用此 API 本身仍会向 Obsidian 发出一个“文件已被修改”的信号，导致操作系统更新文件的“修改时间”为当前时刻。
不用。那是和webdav服务器连接有问题
感谢耐心解答，找到了问题关键。谢谢
大佬牛逼，我以前使用remotely save的时候就发现同样问题，第一次看到了问题来源
感谢作者的工作。
想问一下，目前插件的同步速度如何？之前使用的remotely save插件搭配infini-cloud服务，3000左右文件的库同步速度大概在十几秒到二十秒左右。这可能是remotely save代码过于庞大冗杂导致的。不清楚作者的插件整体的同步速度如何？
emmm……应该与你的网络速度有关