这问题挺典型的，结合你提到“此前多人多次部署成功，但新检出代码的所有人都失败”这个关键背景，大概率是项目目录结构、打包逻辑或者环境配置的一致性出了问题，给你几个具体的排查和解决方向：

1. 确认部署命令的工作目录与main.py的位置匹配 #

Google Cloud Functions要求main.py必须位于部署包的根目录，如果执行gcloud functions deploy命令时的工作目录不是main.py所在的目录，CLI打包出来的包会把main.py放在子文件夹下——即使控制台能看到文件存在，GCF也找不到根目录下的main.py。

• 排查：执行部署命令前，用pwd（Linux/macOS）或cd（Windows）确认当前工作目录是否直接包含main.py。
• 解决：要么切换到main.py所在的目录再执行部署命令，要么用--source参数明确指定main.py所在的路径，比如：

  gcloud functions deploy <redacted> \
    --trigger-http \
    --runtime=python37 \
    --region=europe-west1 \
    --project=<redacted> \
    --entry-point=<redacted> \
    --source=./path-to-main-py-directory
  

2. 检查项目的.gitignore或打包排除规则 #

既然所有新检出代码的人都遇到问题，很可能是项目仓库中新增了.gitignore规则，或者本地环境有全局的git排除规则，导致main.py虽然存在于本地，但打包时被意外排除（不过你提到控制台能看到包内有main.py，这一步可以作为辅助排查）：

• 查看项目根目录的.gitignore文件，确认没有把main.py所在的目录或者文件本身排除在外。
• 执行git check-ignore -v main.py（在main.py所在目录），确认该文件没有被git忽略。

3. 统一团队的gcloud CLI版本 #

不同版本的gcloud CLI可能在打包逻辑上有细微差异，如果之前成功部署的团队成员用的是旧版本，而新检出代码的人安装了新版本，可能会出现打包路径的问题。

• 排查：执行gcloud --version查看当前CLI版本，和之前成功部署的版本对比。
• 解决：统一升级到最新稳定版本，执行：

  gcloud components update
  

4. 手动打包验证部署包结构 #

如果以上方法都没解决，可以手动生成部署包，验证main.py是否在包的根目录：

1. 切换到main.py所在的目录。
2. 执行zip function.zip main.py（如果有依赖文件，比如requirements.txt也要一起打包）。
3. 用Google Cloud控制台手动上传这个zip包进行部署。
   如果手动部署成功，说明是gcloud CLI自动打包时的路径问题，回到CLI部署时重点检查--source参数和工作目录。

5. 确认entry-point参数的正确性 #

虽然错误提示是main.py不存在，但有时候如果--entry-point指定的函数名在main.py中不存在，也可能触发类似的混淆错误。可以确认：

• --entry-point指定的函数名和main.py中定义的函数名完全一致（Python是大小写敏感的）。

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