问题背景
这次原本想做一个自动化链路：把百度网盘中的 `baidusync` 文件夹挂载到 AList，再通过 rclone 同步到 Nextcloud 的家庭共享目录。这样只要在任意设备上把文件保存进百度网盘，家里的 Mac mini 就能自动同步下来，再由 Nextcloud 分发给其他客户端。
这个方案的思路本身是成立的。AList 负责把百度网盘暴露成 WebDAV，rclone 负责在 AList 和 Nextcloud 之间做同步。前期也已经完成了 AList 挂载、rclone remote、Nextcloud WebDAV 和定时任务配置。
现象
问题出现在下载环节。AList 能看到百度网盘里的文件，rclone 也能列出目录，但实际同步某些文件时会失败。
当百度网盘里放入 PDF、DMG、ZIP 等文件后，AList 侧经常可以正常展示文件名，但 rclone 从 AList 下载时会遇到百度返回的拒绝下载错误。也就是说，这不是“挂载失败”，而是“能列目录但不能稳定下载”。
这类问题最容易误判，因为界面里能看到文件，会让人以为 WebDAV 已经完全可用。但自动同步真正依赖的是后续下载动作，列出文件和下载文件在百度网盘第三方接口里并不是同一回事。
排查过程
最开始先确认了 AList 容器、百度网盘挂载、rclone remote 和 Nextcloud WebDAV 都是通的。随后用 rclone 手动检查两边目录，确认百度网盘目录和 Nextcloud 目标目录都能访问。
接着观察失败文件的行为：文件已经能在 AList 中出现，但同步到 Nextcloud 时迟迟没有落地。手动触发同步后，错误集中在百度网盘下载接口返回拒绝，典型表现是第三方接口无法拿到实际文件内容。
再对照 AList 官方百度网盘文档，结论就比较清楚了。AList 文档明确说明，百度网盘 API 对下载有限制；较大的文件下载需要带特定 User-Agent；官方接口稳定但速度慢，非官方接口不保证可用，某些非视频文件还会触发限制类错误。
所以这次的问题不是本地 CPU、内存、Nextcloud 或 rclone 配置本身造成的，而是百度网盘对第三方下载链路的限制导致自动同步不可靠。
参考资料：AList 官方文档中的 Baidu Netdisk 说明，见 https://alistgo.com/guide/drivers/baidu.html
解决方法
最后没有继续围绕 AList 的非官方下载接口折腾，而是改成更稳的链路：
- 百度网盘官方客户端负责把百度网盘中的 `baidusync` 同步到 Mac 本地。
- 本地目标目录直接选在 Nextcloud 客户端管理的 `家庭共享/baidusync` 文件夹中。
- Nextcloud 客户端再把这个本地目录上传到 Nextcloud 服务器。
- 家庭成员的其他设备通过 Nextcloud 客户端接收这个共享目录。
调整后，AList + rclone 方案被停用，只保留配置作为备用记录。AList 容器停止运行，rclone 的定时任务也不再加载，避免和百度官方客户端重复同步同一个目录。
这个方案牺牲了一点“全开源工具链”的纯粹性，但换来了稳定性。百度网盘官方客户端使用的是官方同步链路，面对百度自己的下载限制时更可靠；Nextcloud 则继续负责家庭内部分发。
注意事项
第一，AList 挂载百度网盘适合浏览、临时取文件或轻量使用，但不适合作为所有文件类型都稳定自动下载的基础设施。尤其是安装包、压缩包、较大的 PDF、DMG 这类文件，要提前接受失败的可能。
第二，能在 AList 里看到文件，不代表 rclone 一定能同步成功。判断自动化链路是否可靠，必须实际下载和校验文件是否落到目标目录。
第三，如果本地目录同时被百度网盘官方客户端和 Nextcloud 客户端管理，要确认只使用一个正确的 Nextcloud 本地目录。macOS 上如果出现带日期后缀的重复 Nextcloud 目录，很容易让文件看起来“同步丢了”，其实是同步到了另一个本地副本。
第四，旧的 AList、rclone 配置可以保留，但不要继续启用定时同步。否则官方客户端和 rclone 同时操作同一批文件，反而会增加冲突和排障难度。
总结
这次排障的关键结论是：AList 能挂载百度网盘，不等于它能稳定承担百度网盘自动下载任务。真正的问题不在 WebDAV、rclone 或 Nextcloud，而在百度网盘第三方下载接口本身的限制。
最终方案改为“百度官方客户端同步到本地，Nextcloud 负责家庭分发”。这个结构更符合各个工具的长处：百度官方客户端负责和百度网盘打交道，Nextcloud 负责家庭内的文件同步，AList/rclone 只作为备用方案保留。