它是什么

所谓设定 Google Cloud 专案，先别急着点“创建”。Google Cloud 专案也常叫项目，不是一台机器，而是资源、权限、结算和配额的基本边界。说人话，它像一个带锁、带账单、带用量上限的总盒子：创建 VM、存储桶、数据库、VPC、防火墙，都要挂在它下面；谁能操作、费用算给谁、CPU、IP、API 能用多少，也按这个盒子划分。

对 Linux 运维来说，它相当于一套服务器群、网络、账号和账单的总容器：VM 像服务器，VPC 像网线，服务账号像系统账号，结算账号像财务口径。但它不是 Linux 目录、主机名，也不是 SSH 进去的一台机器，而是云平台的管理边界。

所以设定专案不是只填名称，还要确认这些“出厂设置”：

• 专案 ID：命令和 API 真正认它，全球唯一，创建后通常不能改；名称可重复，别把名称当 ID。
• 所属组织或文件夹：决定权限和策略从哪里继承；个人试用常是“无组织”。
• 结算账号：没绑定，很多资源开不了；绑错，账单会跑到别的部门。
• 默认区域和可用区：影响 VM、磁盘、存储桶落在哪儿，也影响延迟、费用和迁移。
• 可用 API：Compute Engine、Cloud Storage、Cloud SQL 默认不一定全开，没启用会报 service disabled。

先别建资源，为什么要先看？因为小白最容易用错 Google 账号、停留在旧专案，资源建到别处后在控制台里找不到。复制下面整段即可；没装 Cloud SDK 也只会给提示，都是只读操作，不会扣费。

if command -v gcloud >/dev/null; then
  gcloud auth list
  gcloud projects list || echo "还没登录或没有权限，先别建资源。"
  gcloud config get-value project
  gcloud config list
else
  echo "未安装 Cloud SDK：本节先理解概念即可。"
fi

还有个坑：删掉 VM 不代表账单结束，独立磁盘、静态 IP、存储桶可能还在专案里计费；默认项目没切换时，命令行也可能把新资源建到旧项目。记住：先认清总容器，再放机器和数据。

解决什么问题

设定 Google Cloud 项目，先解决的不是「点哪个按钮」，而是给后面所有操作定一个归属。可以把它想成三间带门牌、带锁、各自记账的房间：开发、测试、生产最好各一间。这样在开发里删 VM、改防火墙、跑脚本，不会碰到生产；测试同学也拿不到生产权限；三套环境的账单不会搅成一锅粥，费用一涨，能先判断是哪间房间在烧钱。

分清楚还有个好处：IAM 权限、服务账号、审计日志和预算告警都挂在项目下。谁开了权限、哪个账号调过 API、哪条日志记录改动、哪个预算先报警，都有归属，出事先按项目筛，排障时能快速定位，比在全账号里翻快很多。小白常踩的坑是：把项目当文件夹，以为登录账号就行；命令行其实会记住「上一次的当前项目」，换电脑或 Cloud Shell 后容易沿用旧项目，资源就建错地方。

先复制下面整段到终端执行。第一条会引导你登录并选择或创建项目，同时把「当前项目」写进本地配置；后两条用来复核，确认自己到底站在哪间房间。这个当前项目，就是后续 SSH 登录 VM、配置 VPC、开通 API 和自动化脚本的统一入口。

gcloud init
gcloud config get-value project
gcloud projects list --format="table(projectId,name)"

如果显示的项目不是你要的，重新执行第一条，别往下做。项目 ID 全局唯一，创建后不建议改，命名带环境和简称，例如 gcpok-dev、gcpok-test、gcpok-prod；如果提示找不到 gcloud，改用 Cloud Shell 或先装 Google Cloud CLI；没权限或没绑结算账号会失败，找管理员，别反复重试。

• 后续命令默认作用在「当前项目」，先设好它，才不会把测试 VPC 建到生产里。
• 脚本也读这个入口；测试脚本别借用生产服务账号，别给生产项目 Owner 权限，否则日志只看到同一个身份，排障说不清是谁干的。
• 预算告警按项目各设一条，误删、越权和费用混在一起，才真的被隔开。

怎么上手

第一次设定 Google Cloud 专案（也就是新建项目），别被满屏英文吓到，跟着点一遍就通了。先登录 Google Cloud 控制台，点顶部「新建专案」。

1. 填名称（给自己看，随时能改）和专案 ID（全局唯一，建完不能改，后面命令全靠它，建议小写字母加数字）。
2. 在「位置」里选组织或文件夹；个人练手选「无组织」就行，公司账号千万别选错，不然后面权限会乱。
3. 绑定结算账号：不绑连虚拟机都开不起来。新号有免费额度，顺手去「结算」加个预算告警（比如 50 元），超了发邮件，避免睡一觉收到账单惊吓。

专案默认很多功能是关着的。先去「API 和服务」启用 Compute Engine API，不然等下开 VM 会直接报「未启用」。再到「IAM 和管理」配角色：别图省事给自己挂 Owner，按最小权限给「Compute Instance Admin」就够；以后脚本要跑，单独建个服务账号发密钥，千万别把个人密码写进代码里。

控制台点顺了，再装本地 gcloud（官网 SDK 一路下一步）。装完执行初始化，会弹浏览器让你登录并选刚建的专案：

gcloud init
gcloud config set project my-first-gcp-2024
gcloud config list

把 my-first-gcp-2024 换成你刚记下的专案 ID 再回车。最后一行用来验证当前配置，确认 project 没串号——这是新手最常踩的坑：明明建了 A，命令却默默跑去了旧专案 B，还以为没生效。

回控制台开第一台 VM：区域选离自己近的（如 asia-east1，延迟低），镜像用默认 Debian/Ubuntu 最省心，防火墙规则勾「允许 HTTP/HTTPS」即可，SSH 默认已放通不用手加。等状态变绿，点「SSH」就能在浏览器里连上，顺手做次基础 Linux 巡检：

whoami
uname -a
df -h
free -m
sudo apt update && sudo apt upgrade -y

能看到用户、内核、磁盘和内存就说明真跑起来了。再啰嗦一句：练完记得停掉实例，停了才不扣计算费，光关网页是没用的。

与替代方案对比

把「设定 Google Cloud 专案」想成给资源准备一个带门牌号的收纳箱：网络、主机、权限、日志和账单都挂在下面。结构选错，后面改名、搬资源、拆账单都麻烦。

所有资源共用一个专案最省事，但测试、正式、数据库和同事练习挤在一起，误删规则或给错管理员权限会波及全部。多专案隔离更安全，出事不易连累生产；代价是命名、权限和账单管理更复杂。坑是名字叫「test1」，过一个月没人知道用途。

gcloud init
gcloud config get-value project
gcloud projects list --format="table(projectId,name,projectNumber)"
gcloud services list --enabled --format="table(config.name,state)"
gcloud organizations list --format="table(displayName,organizationId)"

为什么先跑这些？第一条按提示登录并选当前专案，第二条确认现在操作的是哪一个；后面几条列出可见专案、已启用 API 和组织层级。这样能避免把资源建到正式环境，也能提前发现「服务没开」。个人账号看不到组织是正常的。

和自建 Linux 服务器相比，GCP 专案把网络、主机、身份和监控集中管理，不用从装系统、配 SSH、防火墙和监控开始，上线快。但要盯配额和计费：CPU、公网 IP、磁盘、出口流量都有限额或收费，免费额度不等于永久免费。坑是机器忘关、配额不够、没设预算提醒。

和其他云平台的账号或订阅相比，思路相近，都是用一层容器管资源、权限和费用。GCP 更强调专案 ID、API 启用和组织层级：专案 ID 全局唯一且不好改，服务通常要先启用 API，公司还会用组织层级统一管政策。别把显示名称当专案 ID，也别只配 IAM 忘了开 API。

• 怎么选：个人练手可先一个专案；只要分测试/正式、多人协作或准备上线，宁可一开始多建几个，并写清命名、权限和账单规则。

最佳实践

设定 Google Cloud 项目时，先别急着点“创建”。把命名规则写进交接文档：环境用 dev、test、prod，后面依次放业务、区域、负责人，例如 prod-pay-asia-east1-liming。这样一眼知道是谁的、跑在哪里、能不能删。项目 ID 全局唯一，创建后其实不能改，还会出现在服务账号邮箱、日志、账单和脚本里；坑是用 test123 或临时活动名，半年后没人敢动。显示名称可以补充说明，ID 要一次想好。

• 权限：按最小权限给角色，别一上来给 Owner 或 Editor。生产环境一个用途一个服务账号，避免共用个人账号；人离职、改密码或开两步验证，定时任务就可能挂。去“IAM 与管理员 > 审核日志”给生产核心服务开启数据访问审计，Admin Activity 默认已有；别全开所有服务，日志费会涨。
• 上线前：在“结算 > 预算和提醒 > 创建预算”设置月度上限，阈值填 50%、90%、100%，通知负责人和值班邮箱。预算告警不是自动关机，只是提醒；它防的是测试资源忘关导致账单爆。还要查配额、设日志留存、写备份策略：配额不够要提前申请，别等发布当晚才发现机器开不出来；日志留存先按 30 天起步，坑是默认留存太短，排查时没数据；备份对象、频率、保存天数、恢复负责人都写清，Cloud SQL 开自动备份、Cloud Storage 开版本控制，并做一次恢复演练。坑是只备份不演练，真出事才发现没权限或备份过期。
• 复查与交接：每月看未挂载磁盘、预留 IP、已停止实例；看到“未使用”别立刻删，可能是发布或灾备预留。把常用配置、API 清单和创建步骤写成脚本或文档，新人不用靠截图猜，环境也能复现。

下面这段可以直接复制执行；第一行会让你登录并选择项目。它会启用常用 API、建一个生产服务账号、只给写日志和写指标的小角色、导出 IAM 与审计配置、把默认日志桶留存设为 30 天、查配额和结算账号，并列出待复查资源。

gcloud init
PROJECT_ID="$(gcloud config get-value project)"
REGION="asia-east1"
gcloud config set compute/region "$REGION"
gcloud config set compute/zone asia-east1-b
gcloud services enable compute.googleapis.com iam.googleapis.com serviceusage.googleapis.com logging.googleapis.com monitoring.googleapis.com cloudresourcemanager.googleapis.com
gcloud iam service-accounts create prod-app-runner --display-name="prod app runner" --project="$PROJECT_ID" 2>/dev/null || true
SA_EMAIL="prod-app-runner@$PROJECT_ID.iam.gserviceaccount.com"
gcloud projects add-iam-policy-binding "$PROJECT_ID" --member="serviceAccount:$SA_EMAIL" --role="roles/logging.logWriter" --condition=None
gcloud projects add-iam-policy-binding "$PROJECT_ID" --member="serviceAccount:$SA_EMAIL" --role="roles/monitoring.metricWriter" --condition=None
gcloud projects get-iam-policy "$PROJECT_ID" --format='yaml(auditConfigs,bindings)' > iam-policy-audit.yaml
gcloud logging buckets update _Default --location=global --retention-days=30 --project="$PROJECT_ID"
gcloud compute project-info describe --project="$PROJECT_ID" --format='yaml(quotas)'
BILLING_ACCOUNT_ID="$(gcloud billing accounts list --filter='open=true' --format='value(name)' | sed 's#billingAccounts/##' | head -n 1)"
if [ -n "$BILLING_ACCOUNT_ID" ]; then gcloud beta billing budgets list --billing-account="$BILLING_ACCOUNT_ID"; else echo "没有可用结算账号，请先在控制台开通结算"; fi
gcloud compute disks list --project="$PROJECT_ID" --filter='-users:*' --format='table(name,zone,sizeGb)'
gcloud compute addresses list --project="$PROJECT_ID" --filter='status=RESERVED' --format='table(name,region,address,status)'
gcloud compute instances list --project="$PROJECT_ID" --filter='status=TERMINATED' --format='table(name,zone,status)'
{
  echo "设定 Google Cloud 项目记录"
  echo "项目 ID：$PROJECT_ID"
  echo "区域：$REGION"
  echo "启用 API："
  gcloud services list --enabled --project="$PROJECT_ID" --format='value(config.name)' | sort
  echo "当前配置："
  gcloud config configurations list --format='table(name,is_active,properties.core.project,properties.compute.region)'
  echo "创建步骤：登录选项目、启用 API、建服务账号、绑最小角色、设日志留存、预算告警、配额和备份复查。"
} > PROJECT_SETUP.md
cat PROJECT_SETUP.md

上面代码最后几行把配置、已启用 API 和创建步骤落到 PROJECT_SETUP.md，可直接保存为 setup.sh 交接。常见坑是只截控制台图，漏了某个 API 或区域不一致，换台电脑就跑不起来；有文档和脚本，复现、审计、交接都省事。

常见问题（FAQ）

设定 Google Cloud 专案前要准备什么？

准备 Google 账号、结算账号、组织或文件夹归属，以及命名规则。

专案和结算账号是什么关系？

专案绑定一个结算账号，费用按专案归集，便于分账和预算告警。

为什么启用 API 后仍无法创建 VM？

常见原因是权限、配额、区域限制或结算状态异常，逐项检查即可。

可以用 gcloud 切换专案吗？

可以，用 gcloud config set project 专案 ID，再验证当前配置。

新手要不要一开始就分多个专案？

建议至少隔离开发、测试、生产，避免权限和费用互相影响。