Docker 本地能构建，Cloud Run 找不到 requirements.txt：检查上传忽略规则

本地 docker build 正常，但用 gcloud run deploy --source 从源码部署时，云端构建停在 COPY requirements.txt ./，提示：

COPY failed: file not found in build context or excluded by .dockerignore:
stat requirements.txt: file does not exist

这是对应场景的错误示例。.dockerignore 没有排除这个文件，仍然可能失败，因为源码先经过 gcloud 的上传规则，再进入云端 Docker 构建。文件若在上传前被排除，Docker 修改复制路径也找不到它。

本文针对包含 Dockerfile、使用 Cloud Run 源码构建部署的项目，不适用于已经构建好镜像后用 --image 部署的情形，也不讨论跳过构建的源码部署方式。

本地文件存在，不等于上传清单包含它

确认 --source 指向的目录，而不是只看终端当前目录。Dockerfile 中 COPY requirements.txt ./ 的源文件应位于构建上下文根目录；WORKDIR 决定镜像中的目标位置，不会改变上传目录里源文件的查找位置。

在准备上传的源码根目录检查文件名、大小写及所在位置，并查看 .gcloudignore、.gitignore 和 .dockerignore。gcloud 使用上传目录顶层的 .gcloudignore；其中若有下面这行，会在该位置插入顶层 .gitignore 的规则：

#!include:.gitignore

例如 .gitignore 中的 *txt* 会匹配 requirements.txt。这条规则即使原本只想忽略临时文本，也可能通过 include 影响上传。仅检查 .dockerignore 会漏掉这个阶段。

在同一个源码根目录查看待上传文件，不需要立即部署：

gcloud meta list-files-for-upload

清单中没有 requirements.txt，就先检查上传过滤和 --source 路径。如果清单已有文件，才继续核对云端真正采用的 Dockerfile、构建上下文、文件名及 .dockerignore。项目使用自定义忽略文件时，还应确认清单检查与实际部署采用的是同一份规则。

用明确例外修正，不必开放整个目录

先备份现有忽略文件。若根目录 requirements.txt 确实是构建必需文件，可以在 .gcloudignore 中相关排除规则之后加入例外。以下是片段示例，合并进现有文件，保留其他规则：

#!include:.gitignore
!/requirements.txt

最后匹配的规则优先，例外应放在会排除它的规则之后。这里的 /requirements.txt 指上传根目录的文件；文件在子目录时，需要按实际路径处理，若父目录整体被排除，还需处理父目录规则，不能照搬根目录例外。

如果 *txt* 本来就是写错的规则，也可以缩小它的匹配范围。但修改 .gitignore 同时影响 Git 的忽略行为，应确认这样改符合仓库管理意图。只希望改变部署上传时，优先在上传规则中设置明确例外。

不要直接删除整份 .gcloudignore，也不要全局关闭忽略功能来绕过问题。上传规则可能还在保护 .env、密钥、数据导出或其他不应进入云端构建的文件。每次调整后重新查看完整上传清单，既确认依赖文件被包含，也确认敏感文件仍然被排除。

云端重新构建后，分开验收构建与上线

清单正确后，再按原有受控发布流程提交新的源码构建。源码部署会上传代码、消耗构建资源，并可能创建新版本或改变服务流量，应保留当前服务配置与可回退版本，不要为了这条错误额外开放未认证访问。

第一步验收是新的构建已通过 COPY requirements.txt 和依赖安装。后续若在启动、端口或权限阶段失败，属于新的问题，不能继续按“文件没上传”处理。

服务健康、必要接口可用，并且流量符合发布计划，才算这次部署完成。出现问题时先按既有发布流程恢复上一有效版本，再恢复本次误改的忽略规则；不要因为一次 COPY 成功就把旧版本和原配置删掉。