项目

CLI 查看腾讯云 COS 目录

记录我通过本机已配置的 coscmd 查看腾讯云 COS 目录结构，并确认新旧上传目录分布的过程

CLI 查看腾讯云 COS 目录

这篇笔记记录我这次用命令行查看腾讯云 COS 目录结构的过程。目标很直接：我想确认当前 Bucket 里到底有哪些顶层目录，以及 uploads/ 下面现在究竟是旧结构为主，还是新的课程封面目录结构已经开始接管。

这次我主要做了两件事：

  • 用本机已经配置好的 coscmd 检查腾讯云 COS 当前目录结构
  • 确认 uploads/ 下新旧两套上传路径是否并存

先说结果：当前 COS 里老的按日期直挂目录还在，新整理出来的 uploads/course-cover/ 和 uploads/course-cover/thumbs/ 也已经存在，说明新旧结构目前是并行状态。

这次一开始遇到的问题

我最开始直接执行：

coscmd list /

结果命令失败，报错是：

InvalidAccessKeyId

这个报错很直接，说明不是 Bucket 路径有问题，而是本机 coscmd 当前加载到的凭证配置不正确。换句话说，问题出在本地配置文件里的 SecretId、SecretKey 或相关 Bucket 配置，而不是 COS 本身不可用。

我是怎么修复 coscmd 配置的

确认是本地配置问题之后，我重新执行了一次 coscmd config，把账号信息、Bucket 和 Region 重新写回配置文件。

出于安全考虑，这里只保留脱敏后的命令格式：

coscmd config -a xxx -s xxx -b xxx -r xxx

重新配置完成后，配置文件生成在：

/Users/xedczq/.cos.conf

这一点很重要，因为以后如果再碰到 InvalidAccessKeyId，我第一反应就应该先去核对这个文件，而不是先怀疑 COS 目录或者对象路径。

配置恢复后我确认到的基本信息

重新配置成功后，我再次执行目录查看命令，访问就恢复正常了。

当前 COS 的基础信息是：

  • Bucket：yizhoudao-1317126361
  • Region：ap-nanjing

我看到的 COS 根目录当前内容是：

  • qrcode/
  • storage/
  • uploadfile/
  • uploads/
  • x36xhzz.m3u8

这说明当前这个 Bucket 里不只是课程相关资源，还混合存在这些内容：

  • 二维码目录
  • 旧业务静态文件目录
  • 上传文件目录
  • 单独的 m3u8 文件

从目录形态上看，这就是一个已经使用了一段时间、并且业务类型比较杂的存储桶，而不是一个只承载单一模块资源的干净目录。

uploads 目录下的实际结构

接着我执行：

coscmd list /uploads/

确认到 uploads/ 目录下已经存在大量按日期命名的旧目录，例如：

  • uploads/2025-12-02/
  • uploads/2025-12-31/
  • uploads/2026-01-26/
  • uploads/2026-06-23/

与此同时，我也看到了这次新整理出来的课程封面专用目录：

  • uploads/course-cover/

这意味着当前 COS 里实际并存两种上传结构。

旧结构是：

uploads/日期/文件名

新结构是：

uploads/course-cover/日期/文件名
uploads/course-cover/thumbs/日期/文件名

我对当前目录结构的判断

这次看完以后，我的判断很明确：

老系统过去大量使用的，还是最直接的“按日期挂在 uploads/ 下面”的结构。这个结构能用，但目录语义很弱。只看路径本身，很难一眼判断一个文件到底属于哪个业务模块，也不方便后续做分类迁移和资源治理。

而现在新规划出来的课程封面目录已经开始落到：

  • uploads/course-cover/
  • uploads/course-cover/thumbs/

这件事本身很关键，因为它说明课程封面资源已经开始从“通用上传目录”里独立出来。

从工程角度看，这种分层至少有三个直接好处：

  • 课程封面资源路径更稳定，业务语义更清晰
  • 缩略图目录可以独立管理，不再和原图混在一起
  • 后续做批量迁移、脏文件清理、资源对账时更容易处理

这次整理出来的结论

如果把这次结果压缩成一句话，我会这样总结：

老系统原本大量使用的是 uploads/日期/文件名 这种直接按日期挂载的旧结构；而我现在为课程封面单独规划的新结构，已经成功落到了 uploads/course-cover/ 与 uploads/course-cover/thumbs/ 下面。

这说明新规则不是停留在设计层，而是已经真正开始写入 COS。

这次我会保留的常用命令

后面如果我要继续检查目录，最常用的命令就是下面这几条。

查看 COS 根目录：

coscmd list /

查看 uploads 目录：

coscmd list /uploads/

查看新的课程封面目录：

coscmd list /uploads/course-cover/

查看缩略图目录：

coscmd list /uploads/course-cover/thumbs/

如果以后再需要重配 coscmd，我也只保留脱敏格式：

coscmd config -a xxx -s xxx -b xxx -r xxx

小结

这次通过 CLI + coscmd 排查 COS 目录之后，我确认了两件很实际的事：第一，本机原来的 coscmd 配置确实有问题，需要重配才能恢复访问；第二，当前 COS 里的上传结构正处在“旧目录继续存在，新目录已经开始落地”的过渡阶段。

对我来说，这份目录确认非常有价值，因为它把“我以为已经迁好了”变成了“我明确知道现在 Bucket 里到底是什么状态”。后面不管是做课程封面迁移、缩略图规则收口，还是老目录清理，我都可以基于这次确认过的结构继续推进。