GCP国际站 GCP谷歌云服务器运行Nodejs教程
前言：GCP 上跑 Node.js，别让服务器当“谜语人”
Node.js 这东西吧，写代码很爽，部署到服务器后如果你没规划好环境，就会变成“运行可以，但为什么我就是访问不到/端口不通/日志看不到”。好消息是：GCP（Google Cloud Platform）其实挺友好，真要让它配合你跑 Node.js，也完全没问题。
本文会用一种“你照着做就能跑起来”的方式讲清楚。你会看到从创建项目到上线运行的完整流程，并且告诉你哪些地方最容易踩坑。为了不让你只会“照抄”，我也会顺带解释一下背后的逻辑：为什么要开端口、为什么要配置服务账号、为什么有时候你看到的 502 不是世界末日。
你可以把本文当作“Node.js 上云行动指南”。如果你已经有 Node 项目（例如 Express、Nest、Koa 都行），那更容易。
接下来，我们先明确：GCP 上运行 Node.js 有不止一种选择。
选择上云路线：Compute Engine 还是 Cloud Run？
很多同学第一句就问：在 GCP 上跑 Node.js 用哪种？我给你一个简单粗暴的判断：
方案 A：Compute Engine（虚拟机）
你拿到一台“真·服务器”，装 Node、装依赖、启动进程，像管理自己的电脑一样管理它。优点是控制感强、配置灵活；缺点是你要负责运维：重启、进程守护、日志收集等。
方案 B：Cloud Run（托管式容器服务）
你把服务打包成镜像扔进去，Cloud Run 负责运行和弹性伸缩。优点是更省心、扩展更自然；缺点是你要接受容器与镜像思路，并且需要适配无状态服务。
本文主线会以“GCP 上跑 Node.js”为目标来展开。我会先讲 Compute Engine（因为它最直观，适合初学者），再补一段 Cloud Run（因为它更现代、更省心）。你可以根据自己的习惯选择。
准备工作：确认你已有 Node.js 项目
在开始之前，你最好准备一个可运行的 Node.js 服务。比如一个最简单的 Express 项目：
项目结构大概长这样：
server.js 或 app.js：提供接口并监听端口。
package.json：定义依赖与启动脚本。
只要你能在本地跑起来：
node server.js
或者 npm run start
GCP国际站 就可以进入上云环节了。
下面给一个示例（你不需要完全一致，只要满足“监听端口并提供接口”即可）。
Compute Engine：在 GCP 上创建服务器并部署 Node.js
第一步：创建 GCP 项目并启用计费
登录 Google Cloud Console（控制台）。选择或新建一个项目。
注意两点：
1）你需要启用计费（Billing），否则你创建资源时会被“温柔拒绝”。
2）尽量不要用“共享项目里来回折腾”的方式，建议专门建一个用于你的测试项目，方便管理资源和预算。
确认项目创建完成后，进入下一步。
第二步：启用必要的 API
通常你需要启用 Compute Engine 相关 API。你可以在控制台里搜索“Compute Engine”，然后按提示启用。
如果你不小心漏了，有时创建实例会失败，报错信息也不太“讲人话”。启用 API 是最省时间的解决办法。
第三步：创建 Compute Engine 实例（虚拟机）
控制台进入 Compute Engine -> VM 实例（或类似名称）。点击“创建实例”。
关键参数怎么填？我们按“跑 Node.js”来给建议：
1）区域/机型：随便先选能用的，测试阶段不必追求极致。
2）系统镜像：建议选择 Debian 或 Ubuntu（对 Node 用户友好）。
3）启动磁盘：默认够用即可。
GCP国际站 4）网络与防火墙：这里是关键！
创建实例时，通常可以勾选“允许 HTTP 流量”与“允许 HTTPS 流量”。如果你跑的是 3000 端口的服务，那么你还需要允许 3000 端口的入站流量。
如果你忘了后面再补也行，但你会在访问时遇到“怎么不通”。服务器不背锅，你先背锅。
第四步：用 SSH 登录服务器
在 VM 实例列表里点“SSH”。控制台会帮你建立连接。
第一次登录可能需要时间，属于正常。
第五步：在服务器上安装 Node.js 与常用工具
在 Debian/Ubuntu 上，你可以用 apt 安装一些基础工具，然后再安装 Node.js。
建议做法是使用 NodeSource 或 nvm（如果你更爱自由）。为了让你照着不崩，我给一个稳妥思路：优先安装 LTS 版本的 Node.js。
你可以这样思考：
1）更新包列表：sudo apt update
2）安装 curl：sudo apt install -y curl
3）安装 Node.js LTS（方法可用官方推荐的安装方式，版本号你自行选）。
装完后检查：
node -v
npm -v
确认有输出。
如果你发现 node -v 显示不对，那就说明安装没成功或者环境路径没设置。别急，先回到安装步骤。
第六步：上传你的 Node.js 代码
代码上传方式有很多，你选最顺手的：
1）直接在服务器上写（适合极简 demo）。
2）用 git 拉代码（适合你有仓库）。
3）本地打包后用 scp 拷贝（适合你不想配置 git）。
推荐用 git：
在服务器上：
cd 到你的项目目录
git clone 你的仓库地址
然后切到分支。
如果你的仓库需要鉴权（私有仓库），你就需要配置 SSH key 或 token。这里也很常见：你以为是代码问题，实际上是权限问题。
第七步：安装依赖并启动服务
进入项目目录：
npm install
然后启动：
npm run start
确保你的服务确实在监听正确的端口。
这里有个关键点：很多云平台会要求你服务监听端口要可配置（例如由环境变量 PORT 指定）。Compute Engine 没那么“强制”，但你最好也用一个 PORT 环境变量来管理端口，便于后续迁移到 Cloud Run。
例如：
const port = process.env.PORT || 3000
app.listen(port, ...)
启动后你可以查看是否成功：
浏览器访问：外网 IP:端口
或者你在服务器上用 curl 测试：curl http://localhost:端口
如果 localhost 通，外网不通，八成是防火墙/端口没放行。
第八步：设置开机自启（可选，但强烈建议）
你可能希望服务器重启后还能自动拉起 Node 服务。你可以用 pm2 或 systemd。
用 pm2 很快：
npm install -g pm2
pm2 start server.js --name your-app
pm2 save
pm2 startup
按提示执行最后一条命令。
这样服务就能在重启后自动恢复。服务器也不是每次都故意吓唬你，但它总会在某个时刻“让你重新学习运维”。
第九步：查看日志与排查问题
遇到“能启动但访问失败”的情况，不要先慌。按顺序排查：
1）进程是否在运行：ps aux | grep node
2）端口是否监听：sudo ss -tulpn | grep 端口
3）本机 curl 是否通：curl http://localhost:端口
4）防火墙是否放行：GCP 防火墙规则/实例网络策略
5）应用是否报错：应用日志（pm2 logs 或你自己写的日志文件）
如果你看到类似 EADDRINUSE，那就是端口被占用；如果看到找不到模块，那是依赖没装或路径不对；如果看到数据库连接失败，那是环境变量或网络访问问题。
Compute Engine 常见坑位清单（让你少掉头发）
坑 1：应用监听了 127.0.0.1，外网当然访问不到
有些人启动时只绑定到本地地址，例如：
app.listen(port, '127.0.0.1')
这样外部访问会失败。建议绑定到 0.0.0.0：
app.listen(port, '0.0.0.0')
当然，如果你用的是 Express，默认通常就是允许外部访问（但别完全靠“默认”，检查一下更安心）。
坑 2：安全组/防火墙没放行端口
你在浏览器里输入外网 IP:3000，但就是不通。最常见原因就是入站规则没开。
在 GCP 防火墙里增加对应端口的规则（TCP 端口）。测试期间可以先开放，但上线后建议收敛访问来源（例如只允许特定 IP 或通过代理层管理）。
坑 3：环境变量没配，导致服务能跑但功能报错
GCP国际站 比如你在代码里依赖：
process.env.MONGODB_URI
process.env.API_KEY
但服务器上没设置，于是你看到的是接口 500、启动时也许没明显报错。
建议：启动时把关键环境变量校验一下，不要“静默失败”。
坑 4：服务器实例重启后服务没起来
如果你没做 pm2/systemd 自启，你的服务就只是“当时运行”。这在测试阶段还能忍，上线后不忍。
补充：Cloud Run 跑 Node.js（更省心的现代方案）
如果你希望更少运维、更快速上线，Cloud Run 通常是更好的选择。它的思路是：把你的 Node.js 服务打成镜像，上传，然后由 Cloud Run 管理容器运行。
第一步：把服务改成适配 PORT 环境变量
Cloud Run 默认会给你的容器传一个 PORT。你要做的就是监听它：
const port = process.env.PORT || 8080
server.listen(port)
不要把端口写死成 3000，不然你会得到各种“为什么不通”。
第二步：准备 Dockerfile
一个典型 Node.js Dockerfile 结构如下（你可以按项目调整）：
使用 node 镜像作为基础镜像
拷贝 package.json 与代码
npm install
暴露端口
启动命令
注意：Cloud Run 会通过容器的入站端口访问你的服务，所以 Dockerfile 的启动命令与监听端口要对得上。
第三步：构建并部署镜像
控制台里你可以直接选择 Cloud Run 并按向导部署。它会帮你创建镜像与服务。
你也可以走命令行方式，但对于教程来说，控制台更适合初学者。
第四步：设置允许访问与测试
部署后会给你服务 URL。你可以在浏览器访问或调用 API。
如果你遇到 403/权限问题，通常是 Cloud Run 的访问权限设置没放开。你可以选择“允许未验证的调用”或配置 IAM。
如果你遇到 502/容器启动失败，那就回去看 Cloud Run 的日志：一般会明确告诉你容器是否启动、是否端口不一致、依赖是否缺失。
部署后怎么“持续让它活着”：监控与告警建议
跑起来只是第一步，真正的乐趣在于：让它一直稳定运行。
建议至少做两件事：
1）集中日志：用 GCP 的日志查看功能（Cloud Logging），不要手动到处找文件。
2）监控指标：CPU、内存、错误率、响应时间等。
如果你是 Compute Engine：
你可以用系统监控与日志采集工具，或者直接在应用里输出清晰日志（JSON 格式更友好）。
如果你是 Cloud Run：
Cloud Run 的监控与告警集成更自然，你可以更快看到问题发生在哪个版本、哪个请求路径。
完整流程复盘（按步骤检查，别靠祈祷）
GCP国际站 为了让你更快对照自己的进度，我把关键步骤再梳理一遍：
1）准备 Node.js 项目：能在本地启动并监听正确端口。
2）创建 GCP 项目与启用计费。
3）选择计算方式：Compute Engine（虚拟机）或 Cloud Run（托管）。
4）Compute Engine：创建 VM、启用入站端口、SSH 登录、安装 Node、上传代码、npm install、启动服务、配置自启。
5）排查访问：先本机 curl，再防火墙，再应用日志。
6）上线后：监控日志与错误告警，别让“偶发故障”变成“常驻悬念”。
常见问题 Q&A（你可能马上会遇到）
问：为什么我服务器启动了，但浏览器访问不通？
通常是端口未放行或应用没绑定到 0.0.0.0。先本机 curl，再检查防火墙规则与监听端口。
问：我用 Cloud Run，但总是提示启动失败，日志里也没我想看的？
Cloud Run 会在日志里给出容器启动相关信息。优先确认：监听端口使用了 PORT；Dockerfile 的 CMD/ENTRYPOINT 指向正确；依赖没缺失。
问：Node 依赖安装成功但运行报错找不到模块？
可能是启动脚本指向了错误文件，或者工作目录不对。确认你运行的是项目根目录下的启动命令，或者在 systemd/pm2 配置里指定正确的 cwd。
问：数据库连接失败怎么办？
检查环境变量（连接串/账号密码），再检查网络访问（VPC、防火墙、私网访问）。如果用 Cloud SQL，按其推荐方式配置连接和权限。
最后的话：上云不是魔法，是流程
你会发现，无论是 Compute Engine 还是 Cloud Run，上云的核心都很一致：让代码能启动、让端口对上、让网络放行、让日志可追踪。
只要你按步骤走，并且“访问不通先排端口，再排防火墙，再看日志”，基本就不会被服务器牵着鼻子走。
GCP国际站 如果你愿意，我也可以根据你的 Node 项目类型（Express / Nest / Koa）、你当前端口、以及你想用 Compute Engine 还是 Cloud Run，帮你把“部署步骤”进一步精确到你项目的文件名和配置项。你只要把项目的启动方式和 package.json 的 start 脚本贴出来就行。
