部署Node.js应用程序遵循一套通用流程：为生产环境准备应用程序、将代码推送到Git仓库、使用进程管理器配置服务器、通过HTTPS配置反向代理，以及测试在线部署效果。
一、为部署准备Node.js应用程序
一个可部署的Node.js项目，基础包含三个核心文件：
- app.js（应用主文件）
- package.json（项目元数据、依赖项和脚本配置）
- .gitignore（版本控制中需排除的文件清单）
应用程序导入的所有包，都必须在package.json文件的dependencies字段中声明。该文件会告诉npm install命令，服务器需要下载哪些依赖包。
请注意，如果缺少必要的依赖包，即使应用在本地（node_modules中已存在该包）能正常运行，在生产环境中也会崩溃。以下是一个标准的package.json示例：
{
“name”: “node-deploy-test”,
“version”: “1.0.0”,
“description”: “用于部署教程的Node.js示例应用”,
“main”: “app.js”,
“scripts”: {
“start”: “node app.js”
},
“dependencies”: {
“express”: “^4.21.0”
}
}
scripts字段定义了托管平台和进程管理器启动应用的方式。其中”start”: “node app.js”配置项，用于告知服务器以app.js作为应用的入口文件。
Node.js环境变量用于存储不同环境（如开发环境和生产环境）中会变化的配置值，例如端口号、数据库凭证和API密钥等，建议使用环境变量存储这些值，而非硬编码到源代码中。
在应用代码中，可以通过process.env引用这些环境变量，示例如下：
const PORT = process.env.PORT || 3000;
这行代码的作用是：如果存在PORT环境变量，则读取该变量的值；否则，默认使用3000作为端口号。同样的逻辑适用于NODE_ENV变量，大多数托管平台会自动将其设置为production（生产环境）。
将配置信息存储在环境变量中，既能防止敏感数据泄露到代码仓库，也能在不修改代码的情况下，为不同环境调整配置。
二、将应用代码推送到Git仓库
版本控制对于Node.js部署至关重要，它能为代码库的每一次修改创建可靠、可追踪的记录。
如果部署过程中引入了bug，可以在几秒内回滚到上一个可正常运行的提交版本，无需盲目排查问题。
Git是标准的版本控制系统，而GitHub是最常用的Git仓库托管平台。首先，在GitHub上创建一个仓库，步骤如下：
1、登录GitHub，若没有账号，可前往官网注册；
2、在仪表盘点击“New”（新建），然后输入仓库名称，例如node-deploy-test；
3、如果计划后续将仓库关联到托管平台，可将可见性设置为“Public”（公开）；
4、保留其他选项为默认（不勾选README、.gitignore和许可证），点击“Create repository”（创建仓库）。
最简单的文件添加方式是通过浏览器操作：
1、在仓库设置页面，点击“uploading an existing file”（上传现有文件）；
2、将app.js和package.json文件拖拽到上传区域；
3、点击“Commit changes”（提交更改）。
需要注意的是，大多数操作系统会隐藏.gitignore这类点文件（以.开头的文件），因此无法通过拖拽方式上传。建议直接在GitHub上创建该文件：
1、在仓库主页面，点击“Add file”（添加文件）>“Create new file”（创建新文件）；
2、输入文件名.gitignore，并在文件内容中添加以下内容：node_modules/；
3、点击“Commit changes”（提交更改）。
此外，如果电脑上已安装Git，也可以通过Git命令行工具推送所有文件（包括.gitignore），步骤如下：
cd path/to/node-deploy-test
git init
git add .
git commit -m “Initial commit”
git remote add origin https://github.com/your-username/node-deploy-test.git
git push -u origin main
将your-username替换为实际的GitHub用户名。
Git命令行方式更适合持续开发场景：执行git push命令时，只会推送修改的内容，而浏览器上传则需要重新上传所有文件。
三、配置服务器并运行应用程序
服务器配置首先需要安装Node.js，可以通过Node版本管理器（NVM）或系统包管理器进行安装。
推荐使用NVM，因为它允许安装和切换多个Node.js版本，且无需root权限。
需要注意的是，当终端会话关闭或服务器重启时，Node.js进程会停止。这意味着一旦应用崩溃，在有人手动重启之前，应用将一直处于离线状态。
PM2是一款生产级别的Node.js进程管理器，可解决上述问题。它会将应用作为后台守护进程运行，并在应用故障或服务器重启后自动重启应用。
此时，应用会在内部端口（如3000）运行，但用户仍无法通过80或443等标准Web端口访问。要将应用暴露到公网，需要配置反向代理。
四、配置反向代理并启用HTTPS
NGINX等反向代理服务器，会将公网流量路由到运行在内部端口的Node.js应用。
NGINX监听80端口（HTTP）和443端口（HTTPS），接收传入的请求，并将其转发到localhost:3000（或应用使用的其他端口）。用户不会直接与Node.js进程交互。
这种配置还可作为SSL/TLS连接的终止点，使加密管理与应用代码分离，提升安全性。
配置完反向代理后，可使用Certbot配合Let’s Encrypt SSL证书启用HTTPS。
五、测试并监控已部署的应用程序
部署完成后，打开浏览器访问应用的根URL（例如http://domain.tld），测试Node.js应用是否正常运行。主页应能正常加载，并显示预期内容。
如果添加了健康检查路由，可在应用URL后拼接/health，确认其返回如下格式的JSON输出：
{
“status”: “healthy”,
“uptime”: …
}
接下来，通过进程管理器查看Node.js日志。对于PM2，执行pm2 logs命令可查看应用输出和错误信息的实时流。
若需更全面的监控，可执行pm2 monit命令打开交互式仪表盘，该仪表盘会在一个界面中显示CPU使用率、内存消耗、事件循环延迟和日志信息。
作为参考，一个健康的Node.js应用通常满足以下基准：
- 事件循环延迟低于50毫秒
- 标准Express应用内存使用量约为300-500MB
- 正常流量下CPU使用率低于70%
相关推荐：《Ubuntu安装Node.js》
-
广告合作
-
QQ群号：4114653
