Vue 3 项目通常构建为纯静态资源，这让部署到 Google Cloud 可以做得非常轻量。但轻量不代表简单：静态站点需要托管、访问加速、HTTPS 证书、路由回退，还要保证每次发布过程一致。手动在 Cloud Console 中点选不仅效率低，而且会造成环境配置漂移。Deployment Manager 提供了一种声明式方式来描述和管理这些基础设施资源，与 Vue 3 的前端工程化流程结合后，能够实现一键部署和回滚。本文从资源建模和自动化管道两个层面展开，帮助团队建立可复用的部署能力。
Deployment Manager 如何解决 Vue 3 部署痛点
Deployment Manager 是 Google Cloud 原生的基础设施即代码服务，它允许开发者在 YAML 文件中声明存储桶、负载均衡器、SSL 证书等资源，然后通过 gcloud deployment-manager 命令批量创建或更新。与 Terraform 类似，Deployment Manager 会将当前实际状态与配置文件进行比对，只应用差异部分，这极大降低了误操作风险。对于 Vue 3 这种纯前端应用，部署所依赖的云资源种类不多，却对一致性和可重复性要求很高，因此使用声明式管理非常合适。
传统的部署方式通常依赖工程师在控制台手动点击创建 Cloud Storage 存储桶、配置权限、开启静态网站托管，然后在本地执行 npm run build 后再用 gsutil rsync 上传文件。这种方式无法有效地进行版本追踪，一旦团队有新成员加入或者需要回滚到某个历史版本，就会变得非常困难。将基础设施定义纳入 Git 仓库后，任何变更都可以通过 Pull Request 审查，部署记录也被完整保留。
另外，Deployment Manager 还支持引用外部模板和 Jinja 或 Python 模板，能够根据环境参数动态生成资源属性，例如根据分支名生成不同的存储桶名称。这为 Vue 3 应用的多环境部署（开发、测试、生产）提供了灵活的基础。
编写 Vue 3 静态站点的 Deployment Manager 配置
下面是一个基础的 Deployment Manager 配置，用于创建 Cloud Storage 存储桶并开启静态网站托管。这里把 notFoundPage 也设置为 index.html，目的是解决 Vue Router 在 history 模式下刷新页面出现 404 的问题。当访问不存在的路径时，Cloud Storage 会返回 index.html，由前端路由接管路径解析。
resources:
- name: vue-app-bucket
type: storage.v1.bucket
properties:
name: my-vue-app-bucket
location: US
storageClass: STANDARD
website:
mainPageSuffix: index.html
notFoundPage: index.html
defaultObjectAcl:
- entity: allUsers
role: READER
在这个配置中，type 指定了 Google Cloud 资源类型，properties 里的字段对应 Cloud Storage 的 API 参数。defaultObjectAcl 为所有用户授予了读取权限，这样对象才会被公开访问。需要注意的是，如果生产环境对安全要求较高，可以不在存储桶级别开放公开读，而是通过负载均衡的 CDN 回源身份来访问私有桶，再配合 cloudcdn 进行缓存。
如果希望进一步扩展为带 HTTPS 和 CDN 的生产级架构，可以在同一个配置中追加外部 HTTP 负载均衡的相关资源，包括 compute.v1.backendBucket、compute.v1.urlMap、compute.v1.targetHttpProxy 和 compute.v1.globalForwardingRule。这些资源会引用前面创建的存储桶，并自动配置健康检查与转发规则。模板化之后，同一个文件即可描述从存储桶到全球负载均衡的完整拓扑。
执行部署命令时，只需要在项目根目录运行 gcloud deployment-manager deployments create vue-app-deployment --config=deployment.yaml。如果后续修改了配置文件，可以使用 update 子命令应用增量变更，避免删除重建带来的访问中断。
通过 Cloud Build 实现 Vue 3 自动部署
基础设施配置就绪后，还需要把 Vue 3 的构建产物自动上传到存储桶。Google Cloud Build 可以监听 Git 仓库的推送事件，在云上执行构建流程。对于 Vue 3 项目，根目录下的 cloudbuild.yaml 可以定义安装依赖、执行构建、同步文件三个步骤。
steps: - name: node:18 entrypoint: npm args: ['ci'] - name: node:18 entrypoint: npm args: ['run', 'build'] - name: gcr.io/cloud-builders/gsutil args: ['-m', 'rsync', '-r', '-c', '-d', './dist', 'gs://my-vue-app-bucket']
这里使用 node:18 镜像来运行 npm 命令，npm ci 严格按照 package-lock.json 安装依赖，保证构建环境一致性。npm run build 会生成 dist 目录，最后通过 gsutil rsync 的 -c 选项比对校验和，只上传发生变化的文件，-d 选项会删除目标端多余的文件，确保存储桶内容与构建产物完全同步。
在 Cloud Build 的触发器设置中，可以关联 GitHub 或 GitLab 仓库，并指定分支过滤条件。例如生产环境只监听 main 分支，而开发环境监听 develop 分支。触发器创建后，每次代码推送都会自动执行构建，无需手动干预。同时，Cloud Build 会输出完整的日志，方便排查构建失败原因。
为了安全地管理敏感信息，例如部署服务账号的密钥，建议将凭证存储在 Secret Manager 中，并在 Cloud Build 步骤里通过 secretEnv 挂载。不要在 cloudbuild.yaml 中硬编码任何密码或 token。
生产环境优化与常见问题排查
部署完成后，可以进一步优化静态资源的传输性能。由于 Vue 3 构建后的 JS 和 CSS 文件名通常带有内容哈希，这些文件可以设置较长的缓存时间，例如 Cache-Control: public, max-age=31536000。而 index.html 不应该被长久缓存，建议设置 no-cache 或短时缓存，否则用户可能在发布新版本后依然拿到旧的入口文件。在 Cloud Storage 中，可以通过 gsutil setmeta 命令为不同路径的对象设置不同的缓存头。
另一个常见问题是刷新子路由时出现 404。虽然前面在 Deployment Manager 中设置了 notFoundPage: index.html，但如果使用了负载均衡，还需要确认 URL Map 的后端服务没有对 404 做特殊处理，同时检查 CDN 是否缓存了错误响应。对于 hash 模式路由可以忽略此问题，但在生产环境下 history 模式更符合 URL 美观需求，因此需要确保回退规则生效。
排查故障时，可以使用 gcloud deployment-manager deployments describe vue-app-deployment 查看资源的详细状态和错误信息。如果某个资源更新失败，Deployment Manager 会保留失败前已经成功的资源，但配置可能处于部分更新的状态。此时可以先执行 gcloud deployment-manager deployments list 确认部署状态，再根据日志定位具体资源类型。对于存储桶权限问题，可以检查 defaultObjectAcl 是否仍然包含 allUsers 读取权限，或者 IAM 策略是否被后续手动修改覆盖。
最后，建议把 Deployment Manager 配置和 Vue 3 源代码放在同一个仓库中，并在 CI 流程中先应用基础设施变更，再上传构建产物。这样即使基础设施需要扩容或调整，也能与代码版本保持对齐，真正实现工程化部署的闭环。
Vue 3Google Cloud Deployment Manager工程化部署修改时间：2026-08-25 21:09:49