rclone 的 MEGA 文件删后还在列表里，检查硬删除的父子索引

通过 rclone 的 WebDAV 入口删除 MEGA 文件后，原进程仍把文件列出来，再删一次却返回 405；另起一个 rclone 进程查看，文件已经不存在。若启用了 MEGA 硬删除，这个差异应先检查长驻进程中的目录索引，避免反复操作一个已删除的文件。

rclone 1.74.3 的 Linux 容器环境中出现过这种情况，链路包含 WebDAV、combine、crypt 和 MEGA。hard_delete=true 是关键条件；没有这个条件的其他列表缓存问题，不能直接套用同一修复。仅执行 VFS forget 或 refresh，也不能保证修正底层 MEGA 节点关系。

相关依赖的硬删除路径移除了按文件 hash 查找的记录，却在清理父目录子项时取错了对象：查到的是被删除节点本身，真正的父目录 children 中仍有它。修正改为从节点的实际 parent 移除该子项。正式 rclone 1.74.4 已更新到包含这项修正的 go-mega 依赖。

先做只读对照，不要再次删除生产文件。沿用已有 remote，用新启动的 rclone 查询出现问题的目录：

rclone version
rclone lsf 'mega:已有目录'

如果业务是通过 crypt 或 combine 访问，按实际使用的逻辑 remote 再列举对应路径。比较这份结果与原长驻 WebDAV 进程显示的目录项，记录差异属于哪一个入口。新的进程不再显示某个名字，而原入口仍显示它，是定位进程内索引问题的有用线索；单凭一个 405 则不足以证明原因。

升级到含修复的维护版本，并确认长驻服务真正重启使用了新二进制或新镜像。只更新命令行工具，旧 WebDAV 进程不会自动换掉内存中的节点索引。重启前按正常运维流程检查是否还有写入任务，避免中断正在进行的传输。

若需要验证删除流程，应只使用隔离测试目录和可以丢弃的临时文件。删除前确认测试对象可在原入口列出，删除后同时检查原进程的目录列表与新启动命令的列表。两者应一致，后续新增和列举也应正常。不要拿生产文件做重复删除实验，也不要把“文件重新出现”的界面现象直接认作服务端数据恢复。

本题的修复针对 MEGA 硬删除后的父子索引同步。远端实际未删除、软删除回收站语义、其他后端缓存或 crypt 路径映射错误，仍要分别核对。无需为了这一故障清空所有缓存或开启更激进的删除选项。