https://xedczq.cn/tags/cos/Recent content in COS on XEDCZQ的博客Hugo -- gohugo.iozh-cnTue, 23 Jun 2026 00:00:00 +0800https://xedczq.cn/post/cli%E6%9F%A5%E7%9C%8B%E8%85%BE%E8%AE%AF%E4%BA%91cos%E7%9B%AE%E5%BD%95/Tue, 23 Jun 2026 00:00:00 +0800https://xedczq.cn/post/cli%E6%9F%A5%E7%9C%8B%E8%85%BE%E8%AE%AF%E4%BA%91cos%E7%9B%AE%E5%BD%95/<h1 id="cli-查看腾讯云-cos-目录"><a href="#cli-%e6%9f%a5%e7%9c%8b%e8%85%be%e8%ae%af%e4%ba%91-cos-%e7%9b%ae%e5%bd%95" class="header-anchor"></a>CLI 查看腾讯云 COS 目录 </h1><p>这篇笔记记录我这次用命令行查看腾讯云 <code>COS</code> 目录结构的过程。目标很直接：我想确认当前 Bucket 里到底有哪些顶层目录，以及 <code>uploads/</code> 下面现在究竟是旧结构为主，还是新的课程封面目录结构已经开始接管。</p> <p>这次我主要做了两件事：</p> <ul> <li>用本机已经配置好的 <code>coscmd</code> 检查腾讯云 COS 当前目录结构</li> <li>确认 <code>uploads/</code> 下新旧两套上传路径是否并存</li> </ul> <p>先说结果：<strong>当前 COS 里老的按日期直挂目录还在，新整理出来的 <code>uploads/course-cover/</code> 和 <code>uploads/course-cover/thumbs/</code> 也已经存在，说明新旧结构目前是并行状态。</strong></p> <h2 id="这次一开始遇到的问题"><a href="#%e8%bf%99%e6%ac%a1%e4%b8%80%e5%bc%80%e5%a7%8b%e9%81%87%e5%88%b0%e7%9a%84%e9%97%ae%e9%a2%98" class="header-anchor"></a>这次一开始遇到的问题 </h2><p>我最开始直接执行：</p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">coscmd list / </span></span></code></pre></div><p>结果命令失败，报错是：</p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">InvalidAccessKeyId </span></span></code></pre></div><p>这个报错很直接，说明不是 Bucket 路径有问题，而是本机 <code>coscmd</code> 当前加载到的凭证配置不正确。换句话说，问题出在本地配置文件里的 <code>SecretId</code>、<code>SecretKey</code> 或相关 Bucket 配置，而不是 COS 本身不可用。</p> <h2 id="我是怎么修复-coscmd-配置的"><a href="#%e6%88%91%e6%98%af%e6%80%8e%e4%b9%88%e4%bf%ae%e5%a4%8d-coscmd-%e9%85%8d%e7%bd%ae%e7%9a%84" class="header-anchor"></a>我是怎么修复 coscmd 配置的 </h2><p>确认是本地配置问题之后，我重新执行了一次 <code>coscmd config</code>，把账号信息、Bucket 和 Region 重新写回配置文件。</p> <p>出于安全考虑，这里只保留脱敏后的命令格式：</p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">coscmd config -a xxx -s xxx -b xxx -r xxx </span></span></code></pre></div><p>重新配置完成后，配置文件生成在：</p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">/Users/xedczq/.cos.conf </span></span></code></pre></div><p>这一点很重要，因为以后如果再碰到 <code>InvalidAccessKeyId</code>，我第一反应就应该先去核对这个文件，而不是先怀疑 COS 目录或者对象路径。</p> <h2 id="配置恢复后我确认到的基本信息"><a href="#%e9%85%8d%e7%bd%ae%e6%81%a2%e5%a4%8d%e5%90%8e%e6%88%91%e7%a1%ae%e8%ae%a4%e5%88%b0%e7%9a%84%e5%9f%ba%e6%9c%ac%e4%bf%a1%e6%81%af" class="header-anchor"></a>配置恢复后我确认到的基本信息 </h2><p>重新配置成功后，我再次执行目录查看命令，访问就恢复正常了。</p> <p>当前 COS 的基础信息是：</p> <ul> <li>Bucket：<code>yizhoudao-1317126361</code></li> <li>Region：<code>ap-nanjing</code></li> </ul> <p>我看到的 COS 根目录当前内容是：</p> <ul> <li><code>qrcode/</code></li> <li><code>storage/</code></li> <li><code>uploadfile/</code></li> <li><code>uploads/</code></li> <li><code>x36xhzz.m3u8</code></li> </ul> <p>这说明当前这个 Bucket 里不只是课程相关资源，还混合存在这些内容：</p> <ul> <li>二维码目录</li> <li>旧业务静态文件目录</li> <li>上传文件目录</li> <li>单独的 <code>m3u8</code> 文件</li> </ul> <p>从目录形态上看，这就是一个已经使用了一段时间、并且业务类型比较杂的存储桶，而不是一个只承载单一模块资源的干净目录。</p> <h2 id="uploads-目录下的实际结构"><a href="#uploads-%e7%9b%ae%e5%bd%95%e4%b8%8b%e7%9a%84%e5%ae%9e%e9%99%85%e7%bb%93%e6%9e%84" class="header-anchor"></a>uploads 目录下的实际结构 </h2><p>接着我执行：</p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">coscmd list /uploads/ </span></span></code></pre></div><p>确认到 <code>uploads/</code> 目录下已经存在大量按日期命名的旧目录，例如：</p> <ul> <li><code>uploads/2025-12-02/</code></li> <li><code>uploads/2025-12-31/</code></li> <li><code>uploads/2026-01-26/</code></li> <li><code>uploads/2026-06-23/</code></li> </ul> <p>与此同时，我也看到了这次新整理出来的课程封面专用目录：</p> <ul> <li><code>uploads/course-cover/</code></li> </ul> <p>这意味着当前 COS 里实际并存两种上传结构。</p> <p>旧结构是：</p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">uploads/日期/文件名 </span></span></code></pre></div><p>新结构是：</p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">uploads/course-cover/日期/文件名 </span></span><span class="line"><span class="cl">uploads/course-cover/thumbs/日期/文件名 </span></span></code></pre></div><h2 id="我对当前目录结构的判断"><a href="#%e6%88%91%e5%af%b9%e5%bd%93%e5%89%8d%e7%9b%ae%e5%bd%95%e7%bb%93%e6%9e%84%e7%9a%84%e5%88%a4%e6%96%ad" class="header-anchor"></a>我对当前目录结构的判断 </h2><p>这次看完以后，我的判断很明确：</p> <p>老系统过去大量使用的，还是最直接的“按日期挂在 <code>uploads/</code> 下面”的结构。这个结构能用，但目录语义很弱。只看路径本身，很难一眼判断一个文件到底属于哪个业务模块，也不方便后续做分类迁移和资源治理。</p> <p>而现在新规划出来的课程封面目录已经开始落到：</p> <ul> <li><code>uploads/course-cover/</code></li> <li><code>uploads/course-cover/thumbs/</code></li> </ul> <p>这件事本身很关键，因为它说明课程封面资源已经开始从“通用上传目录”里独立出来。</p> <p>从工程角度看，这种分层至少有三个直接好处：</p> <ul> <li>课程封面资源路径更稳定，业务语义更清晰</li> <li>缩略图目录可以独立管理，不再和原图混在一起</li> <li>后续做批量迁移、脏文件清理、资源对账时更容易处理</li> </ul> <h2 id="这次整理出来的结论"><a href="#%e8%bf%99%e6%ac%a1%e6%95%b4%e7%90%86%e5%87%ba%e6%9d%a5%e7%9a%84%e7%bb%93%e8%ae%ba" class="header-anchor"></a>这次整理出来的结论 </h2><p>如果把这次结果压缩成一句话，我会这样总结：</p> <blockquote> <p>老系统原本大量使用的是 <code>uploads/日期/文件名</code> 这种直接按日期挂载的旧结构；而我现在为课程封面单独规划的新结构，已经成功落到了 <code>uploads/course-cover/</code> 与 <code>uploads/course-cover/thumbs/</code> 下面。</p> </blockquote> <p>这说明新规则不是停留在设计层，而是已经真正开始写入 COS。</p> <h2 id="这次我会保留的常用命令"><a href="#%e8%bf%99%e6%ac%a1%e6%88%91%e4%bc%9a%e4%bf%9d%e7%95%99%e7%9a%84%e5%b8%b8%e7%94%a8%e5%91%bd%e4%bb%a4" class="header-anchor"></a>这次我会保留的常用命令 </h2><p>后面如果我要继续检查目录，最常用的命令就是下面这几条。</p> <p>查看 COS 根目录：</p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">coscmd list / </span></span></code></pre></div><p>查看 <code>uploads</code> 目录：</p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">coscmd list /uploads/ </span></span></code></pre></div><p>查看新的课程封面目录：</p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">coscmd list /uploads/course-cover/ </span></span></code></pre></div><p>查看缩略图目录：</p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">coscmd list /uploads/course-cover/thumbs/ </span></span></code></pre></div><p>如果以后再需要重配 <code>coscmd</code>，我也只保留脱敏格式：</p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">coscmd config -a xxx -s xxx -b xxx -r xxx </span></span></code></pre></div><h2 id="小结"><a href="#%e5%b0%8f%e7%bb%93" class="header-anchor"></a>小结 </h2><p>这次通过 <code>CLI + coscmd</code> 排查 COS 目录之后，我确认了两件很实际的事：第一，本机原来的 <code>coscmd</code> 配置确实有问题，需要重配才能恢复访问；第二，当前 COS 里的上传结构正处在“旧目录继续存在，新目录已经开始落地”的过渡阶段。</p> <p>对我来说，这份目录确认非常有价值，因为它把“我以为已经迁好了”变成了“我明确知道现在 Bucket 里到底是什么状态”。后面不管是做课程封面迁移、缩略图规则收口，还是老目录清理，我都可以基于这次确认过的结构继续推进。</p>