rclone 访问 S3 前缀报 HEAD 403，区分对象探测与目录列举

S3 上的“目录”通常是对象键的共同前缀。rclone 初始化一个路径时，需要判断它指向单个对象，还是包含子项的前缀。HeadObject 返回 403，并不能单独回答这个问题：访问受限时，探测请求可能既无法确认对象存在，也无法确认它不存在。

这一判断路径出现过两种症状。rclone 1.71.2 的单文件复制可能静默地没有传输；1.74.2 在 macOS 上访问前缀时，则可能直接报 HEAD 403。它们需要一起检查“错误如何影响文件与前缀分类”，不能只凭后一个版本的报错推断为全新的权限故障。

正式 1.74.4 包含新的补充判断：HEAD 失败后尝试查看该路径下是否有子项，确实存在子项时按前缀处理。它没有凭空获得读取权限，也没有把任意 403 变成成功。列表权限不足、空前缀或单个对象本身不可读，仍需按实际权限与对象键判断。

先用已配置 remote 做只读检查。以下路径都应替换成已知存在的对象或前缀：

rclone version
rclone lsf 's3:bucket/已知非空前缀'
rclone lsjson 's3:bucket/已知非空前缀' --recursive
rclone lsjson 's3:bucket/已知对象.txt' --stat

分开保存三个命令的退出码与错误。确认被列出的键确实位于目标前缀下，不能只因某个父目录可列举就认为目标文件可读。日志可用于判断失败发生在 HEAD 还是后续列表，但分享前应清理签名 URL、凭据和业务对象名。

若诊断与分类问题一致，升级到包含修复的维护版本，再以同一身份和同一组路径重复检查。对于原先“复制命令成功但什么也没传”的场景，还要核对预期对象是否真的到达目标，以及文件大小等业务校验是否符合预期。不要用退出码替代传输结果。

权限检查应围绕实际用途：列举非空前缀与读取其中对象是不同操作。保留组织现有的最小权限策略，不要为了排除 HEAD 403 给整个 bucket 开放读取或写入权限。如果升级后仍无权列举子项，补充探测也无法替你完成前缀识别。

这项修复适合处理路径类型判断受 HEAD 错误干扰的情况。它不能修复错误的 endpoint、区域、签名、代理规则或真实对象读取拒绝。验收时把“前缀已正确识别”和“目标对象可读取”分开记录，才能知道接下来该查哪一层。