很多 Node.js 应用在 Ubuntu 上都能很快跑起来，但真正进入长期运行阶段后，问题往往集中在版本混乱、权限过大、性能吃紧和排障困难。下面按安装、安全、性能与运维四个环节拆开说，尽量保留可直接上手的命令和配置，同时也说明哪些做法更适合开发机，哪些更偏向生产环境。
安装与版本管理：先把版本策略定下来
在 Ubuntu 上部署 Node.js，第一步不是急着安装，而是先确定你的机器要服务于哪类场景：如果同一台机器需要兼顾开发、测试，版本切换能力更重要；如果是企业环境或生产服务器，版本一致性和可控升级更关键。
开发和测试环境优先用 NVM
更灵活的方案是使用 NVM（Node Version Manager）。它的核心价值是允许一台机器同时安装多个 Node.js 版本，并按项目切换，不依赖 Ubuntu 自带仓库，也不会被系统仓库中偏旧的版本拖住。
安装命令如下：
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash
安装完成后，可以用下面的命令安装和切换版本：
nvm install --lts
nvm use
这套方式特别适合本地开发、持续集成测试或需要同时维护多个项目的主机。它的优势不只在“方便切换”，更在于把不同项目的运行环境隔离开，减少版本冲突。
生产环境更看重固定版本时，可用 NodeSource APT 仓库
如果你的部署目标是固定版本、统一环境，NodeSource APT 仓库会更适合。相比 Ubuntu 默认仓库，它通常能提供更明确、更新也更及时的 Node.js 版本。
典型步骤如下：
sudo apt remove --purge nodejs
curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
sudo apt install nodejs
这种方式的优点是便于在多台服务器上复现同样的环境，适合生产环境、企业内部标准化部署以及需要和系统级运维流程配合的场景。
为什么不建议直接用 Ubuntu 默认仓库
很多教程会直接让你执行 apt install nodejs，但如果不额外处理仓库来源，最终拿到的往往是较旧版本。旧版本不仅意味着缺少新特性，更直接的问题是安全更新和性能改进跟不上，后续维护成本会越来越高。
因此，一个更稳妥的判断标准是：
- 需要多版本切换，用 NVM；
- 需要统一版本和生产部署，用 NodeSource；
- 尽量不要长期依赖 Ubuntu 默认仓库中的 Node.js。
安全加固：先缩小暴露面，再处理常见攻击
Node.js 应用上线后，最先要守住的不是某个框架配置，而是运行权限、传输加密、依赖安全和敏感信息管理这几条底线。它们处理不好，后面做再多优化也很难弥补。
不要用 root 直接启动应用
最基本的一条，是不要用 root 用户直接运行 Node.js 服务。更安全的做法是为应用创建专用用户，例如 nodeuser，并把应用目录权限交给这个用户。
操作方式如下：
adduser nodeuser
chown -R nodeuser:nodeuser /path/to/app
sudo -u nodeuser node app.js
这样做的意义很直接：即使应用自身出现漏洞，攻击者拿到的也只是受限用户权限，而不是整台机器的最高权限。
HTTPS 要作为默认配置，而不是上线后补做
对外提供服务时，应强制使用 HTTPS。通过 SSL/TLS 加密传输，可以降低中间人攻击和数据被窃取的风险。文中给出的做法是使用 Let’s Encrypt 证书，并在 Node.js 中直接加载证书文件：
const https = require('https');
const fs = require('fs');
const options = {
key: fs.readFileSync('/etc/letsencrypt/live/yourdomain.com/privkey.pem'),
cert: fs.readFileSync('/etc/letsencrypt/live/yourdomain.com/fullchain.pem')
};
https.createServer(options, (req, res) => {
res.writeHead(200);
res.end('Secure connection established');
}).listen(443);这段代码的重点不只是“能监听 443 端口”，而是提醒你把证书管理纳入部署流程，而不是等到需要外部访问时再临时补做。
依赖漏洞、输入风险和配置泄露要一起管
Node.js 项目的风险很大一部分来自依赖链。至少要定期执行 npm audit 检查已知漏洞；如果需要自动化修复或持续监控，也可以引入 Snyk 这一类第三方工具。
在 package.json 中锁定依赖版本同样重要，例如：
"express": "^4.18.2"
这样可以减少意外升级带来的行为变化和安全风险。
针对 Web 常见攻击，处理思路也应尽量明确：
- XSS：使用
helmet设置安全 HTTP 头，例如Content-Security-Policy；或者用escape-html转义用户输入。 - CSRF：使用
csurf生成并校验 CSRF 令牌。 - SQL 注入：使用参数化查询，或采用 ORM，比如 Sequelize，避免手写字符串拼接 SQL。
最后，数据库密码、API 密钥等敏感信息不要写进代码仓库。更常见的做法是放进 .env 文件，再通过 dotenv 加载：
DB_PASSWORD=your_secure_password
API_KEY=your_api_key_here业务代码里再通过 process.env.DB_PASSWORD 读取。这样至少能把配置与代码分开，也更方便在不同环境间切换。
性能优化：围绕并发、阻塞和资源上限做调整
Node.js 的性能优化，核心不是盲目“提速”，而是找出阻塞点、把单进程能力用满，并尽量降低不必要的内存与系统开销。Ubuntu 服务器上常见的优化动作，基本都围绕这几件事展开。
利用多核 CPU，不要只跑单进程
Node.js 本身是单线程事件循环模型，但在多核机器上完全可以借助 cluster 模块启动多个工作进程，共享同一端口，把 CPU 资源吃满。
const cluster = require('cluster');
const os = require('os');
if (cluster.isMaster) {
for (let i = 0; i < os.cpus().length; i++) cluster.fork();
cluster.on('exit', (worker) => console.log(`Worker ${worker.process.pid} died`));
} else {
require('./app.js'); // 启动应用
}这段代码的思路很简单：主进程负责按 CPU 核心数拉起 worker，worker 再真正承接请求。对于高并发服务，这通常比单进程部署更接近生产实际。
避免同步 API 阻塞事件循环
如果应用里充满同步 I/O，Node.js 的单线程优势就会被直接抵消。像 fs.readFileSync()、child_process.execSync() 这样的调用，都可能在关键路径上卡住事件循环。
更稳妥的方式是改用异步 API，例如 fs.promises.readFile()、child_process.exec()。遇到大文件读取或网络传输时，进一步用 Stream 处理会更合适，例如 fs.createReadStream().pipe(res)，这样可以减少一次性把数据全部读入内存的压力。
内存泄漏和进程管理要一起看
很多 Node.js 服务前期压测正常，但运行一段时间后出现响应变慢，问题未必在 CPU，更可能在内存泄漏。几个常见点需要格外注意：
- 无用事件监听器要及时移除，可用
emitter.removeListener()清理； - 尽量避免滥用全局变量，例如
global.user = req.user； - 在适合的场景下，用
Map代替Object，提升查找效率并减少结构混乱。
如果应用确实需要更高内存上限，可以显式指定参数：
node --max-old-space-size=4096 app.js
这里的 4096 表示把可用内存上限调整到 4GB，但这只能缓解内存压力，不能替代对泄漏问题的定位。
在实际托管中，PM2 依然是高频选择，因为它同时解决了守护进程、日志和多实例管理问题。常用命令包括：
pm2 start app.js -i max
pm2 monit
pm2 logs
其中 -i max 会按 CPU 核心数启动实例，适合快速把多核能力利用起来。
系统层参数也会限制吞吐能力
应用代码本身调好了，如果系统连接队列和文件描述符太小，最终也会卡在内核层。文中的建议是修改 /etc/sysctl.conf，例如：
net.core.somaxconn = 4096
# 增加连接队列长度
net.ipv4.tcp_max_syn_backlog = 4096
# 增加SYN队列长度
net.ipv4.tcp_tw_reuse = 1
# 允许重用TIME-WAIT状态的连接
net.ipv4.tcp_fin_timeout = 30
# 缩短TIME-WAIT超时时间修改后执行：
sudo sysctl -p
同时，把文件描述符限制提高到更合理的水平：
ulimit -n 65535
如果希望长期生效，则需要同步写入 /etc/security/limits.conf。这类调整是否必要，可以根据连接量、并发峰值和错误日志来判断，不建议在不了解现网负载前一次性改得过大。
监控与维护：把排障能力留在日常，而不是留到故障时
应用真正进入稳定运行阶段后，监控和维护的价值会迅速超过“部署成功”本身。因为线上问题很少提前打招呼，你能否快速定位，往往取决于日志、性能数据和更新策略是否提前准备好。
日志至少要分级、落盘，并能回看错误
日志体系首先要做到结构化、分级和可保存。使用 winston 或 pino 这类日志库，是比较常见的做法。文中给出了一个 winston 配置示例，将 error 与通用日志分别写入不同文件：
const winston = require('winston');
const logger = winston.createLogger({
level: 'info',
format: winston.format.combine(
winston.format.timestamp(),
winston.format.json()
),
transports: [
new winston.transports.File({ filename: 'logs/error.log', level: 'error' }),
new winston.transports.File({ filename: 'logs/combined.log' })
]
});
logger.info('Application started');这样的配置至少能满足两类需求：一是保留错误现场，二是为后续接入 ELK Stack 这类远程日志服务打基础。
性能诊断既可以用内置工具，也可以上 APM
Node.js 自带的诊断能力其实已经能处理不少问题。比如：
node --inspect app.js：配合 Chrome DevTools 查看 CPU 和内存表现；node --prof app.js：生成性能分析报告；node --prof-process isolate-0xnnnnnnnnnnnn-v8.log：解析性能日志。
如果业务更复杂，或者需要长期可视化监控，则可以考虑 New Relic，或者 Prometheus + Grafana 组合。前者偏全栈 APM 和错误追踪，后者更适合自定义指标和大规模监控场景。
更新与备份不能缺席
最后一件常被低估的事，是更新和备份。Node.js 自身、npm 以及项目依赖都需要定期维护，常见命令包括：
nvm install --lts
npm install -g npm
npm update
与此同时，应用代码和数据库也要定期备份。代码层可以借助 git 管理版本，数据库则可使用 mysqldump 等工具做周期性备份。真正稳妥的上线策略，不只是“服务已经跑起来”，而是出了问题后还能恢复、能回滚、能查清原因。
部署时可以优先落实的几项原则
如果把整篇内容浓缩成一套可执行判断，Ubuntu 上的 Node.js 最佳实践大致可以归纳为四点：版本管理不要依赖默认仓库，权限和密钥管理先于业务上线，性能优化要同时关注代码与系统参数，监控维护要在故障前准备好。这样做的结果，不只是让应用“能跑”，而是让它在版本升级、流量上涨和异常恢复时都更可控。
