把群晖的 WebDAV 挂到访达（Finder）里，点进一个几百个文件的目录，然后开始看菊花转。大部分人的结论是服务端太慢。
多数时候不是。访达的 WebDAV 客户端话特别多，你等的其实是它自己。
打开一个目录，背后是几百次请求
访达把一个目录显示出来，大致要付出这些代价。
- 一次 Depth 1 的 PROPFIND，把目录里的条目列出来。这一步没问题，一来一回而已。
- 紧接着一连串后续 PROPFIND：逐个检查条目、把刚拿到的属性再确认一遍、连你只是鼠标扫过的子目录也顺手看一眼。
- 每进一个目录读一次 .DS_Store，退出时再写一次，好把视图设置存下来。
- 几乎给每个文件都探一次 AppleDouble 兄弟文件。目录里有 report.pdf，访达就会再去找一次 ._report.pdf。对一台从没见过 Mac 的服务器来说，这些全是 404，而一次 404 的往返开销和 200 一模一样。
- 挂载时探测锁支持。访达在意服务端是不是 WebDAV class 2，不声明 LOCK 的服务端有可能被挂成只读，还不给你一个明确的报错。
- 响应最好带 Content-Length。访达对 chunked 的响应不太友好，服务端为此常常被迫多做一层缓冲。
算一下账就明白了：300 个文件，每个平均三四次请求，服务器在 40 ms 之外，光是等就要四十秒左右，此时一个字节的文件内容都还没开始传。这里面没有一点是带宽问题，全是延迟乘请求数，换多粗的宽带都没用。
所以同一台服务器，用 curl 戳一下感觉飞快，交给访达就变成另一副样子。
WebDAV 速度优化，真正值得改的只有一条命令
让访达别再往网络卷上写 .DS_Store：
defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE
改完注销重登一次再看效果。两个必须说清楚的代价：这是按用户生效的设置，对所有网络卷都起作用，SMB 共享也跑不掉；代价是这些卷上的视图设置不再被保存。已经写出去的 .DS_Store 不会自己消失。
剩下能做的，都是在减少请求数
- 关掉图标预览。菜单栏「显示」→「查看显示选项」，取消勾选「显示图标预览」。否则访达为了画个缩略图会真的去读文件内容。
- 目录结构能自己定的话，尽量别让单层超过几百个条目。请求数是跟条目数走的，一个平铺五千个对象的目录属于最差情况。
- 在大目录里干活时用列表视图，别用图标视图或画廊视图。
- 批量搬运别走挂载。用专门的 WebDAV 客户端，或者直接在 AnyStorage 里传，一条连接搞定，不用让访达在中间指挥交通。
你会发现这些手段没有一个能让单次往返变快，它们只是在减少往返次数。那另一半自然就该往延迟上想。
把往返放到本地回环上
请求数砍不动，就砍延迟。
AnyStorage 的做法就是这个思路：WebDAV 服务端跑在你自己这台机器上，而不是公网另一头。侧边栏进「服务」，切到 WebDAV 标签页，点启动。默认端点是 http://127.0.0.1:3211，端口可以改（1 到 65535），和别的服务撞了换一个就行。HTTP Basic 认证始终开着，默认用户名 anystorage，首次使用时生成一个 24 位随机密码，两者都能改，旁边都有复制按钮。然后在访达里「前往」→「连接服务器」，或者直接 Cmd+K，粘贴 http://127.0.0.1:3211，以注册用户身份用这组账号密码登录。
访达并没有变乖，PROPFIND 风暴照样刮，._ 探测照样探。区别在于这些请求全都走回环，一个来回不到一毫秒。几百次乘以一个很小的数，还是很小。
app 里当前处于已连接状态的存储，都会作为一个文件夹出现在 WebDAV 根目录下，名字就是连接名。阿里云盘、阿里云 OSS、腾讯云 COS、S3、Cloudflare R2、SFTP、本地文件夹，一共支持 20 种连接类型。真正还要走网络的只剩文件内容本身，而读取是流式的、支持 HTTP Range，所以在 QuickTime 里拖进度条只会取需要的那一段，不用把整个文件拉下来。
哪些问题它解决不了
访达终究还是访达，本地端点也变不出你的云厂商没给的吞吐。
- 一个前缀下面挂着五万个对象，列出来还是慢，因为慢在后端的列举接口。回环省掉的是访达的开销，不是底下那次 API 调用。
- 免费版的 WebDAV 服务是只读的。读写属于 Pro；Pro 用户也可以主动把它设成只读。
- 当前版本没有 TLS，地址是明文 http，Basic 凭据也是明文，所以默认只监听 127.0.0.1。开启局域网访问会绑定 0.0.0.0，app 会明确弹出警告再让你继续。
- 没有真正的文件锁，两台机器同时改同一个文件不会有任何保护。别把它当团队协作的底座用。
- app 重启之后，某个连接要在 app 里打开过一次，才会出现在 WebDAV 根目录下，因为连接是懒加载的。新建的连接不用重启服务就能看到。
如果这些都做完访达还是让你烦躁，那就在 app 里浏览，把挂载留给那些非要一个真实路径不可的程序。
常见问题
Finder（访达）用 WebDAV 为什么这么慢
因为访达的 WebDAV 客户端发出的请求远多于这件事需要的数量，你等的是请求次数，不是带宽。显示一个目录就要付出：一次 PROPFIND 把目录列出来，紧接着对单个条目的一连串 PROPFIND，进目录时读一次 .DS_Store、出目录时再写一次，以及几乎给每个文件都探一次 AppleDouble 兄弟文件——有 report.pdf 就会再去找 ._report.pdf，在一台从没见过 Mac 的服务器上那是 404，而 404 的往返开销和 200 一模一样。三百个文件、每个三到四次请求、服务器在 40 ms 之外，那就是文件内容还没动一个字节就已经过去约四十秒，所以换更快的宽带并不管用。真正能动的只有两个方向：减少往返次数（禁止访达往网络卷写 .DS_Store、关掉图标预览、改用列表视图），以及缩短每一次往返，也就是把 WebDAV 端点放到 127.0.0.1 上。