Cloud Build执行gsutil rsync部署GCS站时的访问异常及选型建议

会不会访问到上传未完成的文件 #

• GCS的对象写入是原子级保障的，根本不存在“上传到一半的残缺文件被用户访问到”的情况。哪怕你用gsutil -m开启多线程并发上传，单个文件只要没有完全写入完成，外部用户访问就会直接返回404，不会读到不完整的文件内容，这层规则是存储层面固定的，和同步命令无关。

用户会不会感知到访问异常、数据不一致 #

你当前的rsync命令组合存在两个典型的时序风险，这才是引发异常的核心原因：

• rsync遍历源文件的顺序完全由本地文件系统决定，不保证index.html这类站点入口文件最后同步。如果同步过程中新的index.html先被上传到桶里，而它引用的新JS、CSS chunk文件还在传输队列中，此时访问站点的用户就会拿到指向不存在资源的入口文件，出现资源404、白屏、样式错乱的问题。
• 命令里加的-d参数会在同步过程中删除目标桶里源目录不存在的旧文件。如果同步到中途，新的入口文件已经上线，旧的chunk文件已经被清理，刚好在这个时间窗口访问的用户就会直接加载失败。
• 如果你是已经在浏览老版本站点的存量用户，只要不主动刷新页面、不触发需要拉取新资源的路由跳转，不会感知到任何异常——老版本的资源已经在浏览器缓存中加载完成，不受后端同步操作的影响。

同步操作的流畅度 #

• gsutil -m rsync的吞吐完全满足中小型Vue项目的构建产物同步需求，一般几十MB到上百MB的构建包，全量同步最多持续几十秒，同步速度本身不会成为瓶颈。但速度快不代表能抵消上面提到的时序问题，哪怕同步只持续10秒，这个窗口期内访问的用户依然可能碰到异常。

是否需要改用Cloud Run托管 #

• 纯静态Vue SPA场景下，完全没有必要切换到Cloud Run。GCS搭配Cloud CDN是托管这类静态站点成本最低、访问延迟最优的方案，你当前遇到的潜在异常完全可以通过调整同步流程解决，不需要替换托管载体：
  • 调整同步顺序：先把所有非入口的静态资源（JS、CSS、图片、字体）全部上传完成，最后再同步index.html这类入口文件，从根源上避免入口先上线、资源没就位的问题。
  • 拆分清理操作：第一次同步只做新文件的上传，等所有资源、入口文件都同步完成后，再单独执行带-d的清理操作，删掉老版本的冗余chunk文件，避免同步中途删文件引发的404。
• Cloud Run更适合需要服务端渲染、边缘请求逻辑改写的动态站点场景，纯静态内容部署到Cloud Run反而会引入额外的网络跳数，拉高访问延迟，还会产生不必要的计算资源成本。

内容的提问来源于stack exchange，提问作者deniable_encryption