在 CentOS 上部署 Node.js 项目，难点通常不在某一条命令，而在于步骤之间是否衔接正确：Node.js 版本是否合适、端口是否放行、进程是否能托管、域名请求是否真正转发到了应用。下面按上线顺序把整套流程重新梳理一遍，保留原有命令和配置，并补出每一步该检查什么，方便你从“能启动”走到“能稳定对外提供服务”。
先完成系统准备
正式部署前，先更新系统并安装常用基础工具。这里的 wget 和 git 分别用于下载资源和拉取代码，属于后续步骤会直接用到的基础依赖。
sudo yum update -y
sudo yum install -y wget git这一步做完后，至少要确认两件事：系统软件包已更新，后续拉取项目代码时不会再缺少 git。
安装 Node.js 与 npm
如果项目没有特殊版本要求，可以按原文做法通过 NodeSource 仓库安装 Node.js 18.x。这一版本对大多数常见项目都够用，同时也便于后续直接获得对应的 npm。
curl -sL https://rpm.nodesource.com/setup_18.x | sudo bash -
sudo yum install -y nodejs
# 验证安装
node -v
# 应输出v18.x.x
npm -v
# 应输出对应版本这里的关键不是“装完就算结束”，而是确认版本输出正常。只有 node -v 和 npm -v 都返回预期结果，后面的依赖安装和进程托管才有基础。
放行 HTTP 与 HTTPS 端口
如果服务器启用了防火墙，必须提前开放 Web 访问所需端口。原文给出的做法是放行 80 和 443，分别对应 HTTP 与 HTTPS。
sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --reload这一步的作用很直接：不放行端口，即使应用本身已经启动，外部访问也进不来。尤其在后面启用 Nginx 和 SSL 后，这两个端口会成为标准入口。
把项目部署到服务器
项目上线前，先把代码放到目标目录。原文提供了两种方式：通过 Git 克隆，或者手动上传。若项目本身已经使用 Git 管理，优先选择克隆方式，后续更新更省事。
方式一：通过 Git 克隆项目
推荐把项目放到固定目录，例如 /var/www/myapp，便于后续统一管理。
mkdir -p /var/www/myapp && cd /var/www/myapp
git clone <your_project_repo_url> .
# 克隆项目到当前目录方式二：手动上传项目
如果代码不方便直接从仓库拉取，也可以先在本地打包，再通过 scp 上传到服务器。
scp -r /local/project/path user@server_ip:/var/www/myapp
cd /var/www/myapp无论使用哪种方式，做完后都应确认项目目录中已经存在 package.json 和实际入口文件，否则下一步依赖安装或 PM2 启动都会失败。
只安装生产环境依赖
进入项目目录后，根据 package.json 安装依赖。这里的重点是生产环境部署通常不需要 devDependencies，省掉这部分可以减少安装体积和不必要的依赖风险。
npm install --production
# 或使用yarn（需提前安装：sudo npm install -g yarn）
yarn install --production如果你的项目明确依赖某个包管理器，就按项目原本约定执行；不要混用安装方式，否则可能出现锁文件不一致、线上依赖版本漂移等问题。
用 PM2 托管 Node.js 进程
Node.js 项目如果直接用 node app.js 启动，一旦终端断开或进程崩溃，服务就会中断。PM2 的价值就在这里：后台运行、异常自动重启、进程列表持久化，以及开机自启动。
sudo npm install -g pm2
# 全局安装PM2
pm2 start app.js --name "my-node-app"
# 启动应用（app.js为入口文件，按项目实际修改）
pm2 sa ve
# 保存当前进程列表
pm2 startup
# 生成开机自启动脚本（按提示执行生成的命令，如`sudo env PATH=$PATH:/usr/bin /usr/lib/node_modules/pm2/bin/pm2 startup systemd -u root --hp /root`）这里有三个检查点最重要：
- 入口文件是否真的是
app.js，如果项目入口不同，需要按实际修改。 pm2 save是否执行成功，决定重启后能否恢复进程列表。pm2 startup输出的命令是否已按提示执行，否则不会真正写入系统自启动。
用 Nginx 做反向代理
Nginx 不是 Node.js 项目运行的前提，但在生产环境中通常值得加上。它可以接管 80/443 端口，对外暴露统一入口，再把请求转发到 Node.js 实际监听的应用端口，例如 3000。
sudo yum install -y nginx
# 安装Nginx
# 配置反向袋里（编辑默认配置或新建站点配置）
sudo vi /etc/nginx/conf.d/myapp.conf配置文件可按下面内容填写，将 your_domain.com 替换成你的域名或 IP，把 3000 改成应用真实端口：
server {
listen 80;
server_name your_domain.com;
location / {
proxy_pass http://localhost:3000;
# 转发到Node.js应用
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}配置完成后，重启并设置 Nginx 开机自启：
sudo systemctl restart nginx
sudo systemctl enable nginx
# 开机自启动这一层配置的判断标准很明确：用户访问域名后，请求应先到 Nginx，再由 Nginx 转发到本地 Node.js 端口。若域名打不开、返回 502 或始终访问不到应用，问题通常就出在这里或 PM2 进程本身。
补上 HTTPS 证书
如果项目准备正式对外提供服务，建议继续配置 SSL。原文采用的是 Let's Encrypt 和 Certbot，这也是 CentOS 上较常见的一套免费 HTTPS 方案。
sudo yum install -y certbot python3-certbot-nginx
# 安装Certbot
sudo certbot --nginx -d your_domain.com
# 自动配置Nginx HTTPS
# 按提示完成证书申请（需验证域名所有权）
# 证书自动续期（Certbot会添加cron任务）要注意的是，证书申请依赖域名解析已经正确指向服务器，而且外部可访问 80 端口。否则即使 Certbot 已安装，也无法完成域名所有权验证。
上线后怎么验证部署成功
部署完成后，不要只看命令有没有报错，更要做最基础的上线核验。原文给出的检查点可以直接沿用：
- 访问
http://your_domain.com（或https://your_domain.com），确认应用正常运行。 - 查看 PM2 进程状态：
pm2 list（应显示应用为online）。 - 查看应用日志：
pm2 logs my-node-app（排查启动或运行错误）。
如果页面无法打开，可以按顺序排查：Node.js 应用是否在监听端口、PM2 进程是否在线、Nginx 是否成功转发、80/443 是否已放行、域名是否正确解析到服务器。把这些点串起来看，部署问题通常都能比较快定位。
