在CentOS上跑Node.js应用，遇到运行错误是常有的事。别着急，下面梳理了一套常见的排查思路和解决方法，基本能覆盖大部分场景。先不说废话，直接上干货。

版本兼容性检查

版本不匹配的问题很常见，比如应用需要Node.js 14.x，但系统装的是16.x，就可能出现各种奇怪的问题。先用下面两个命令确认一下当前版本：

node -v
npm -v

如果版本不对，怎么办？最推荐的方式是用nvm（Node Version Manager）来管理多版本Node.js，这样可以避免系统级安装带来的冲突：

# 安装nvm
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash
source ~/.bashrc  # 使nvm生效

# 安装指定版本Node.js（如14.x）
nvm install 14

# 切换至该版本
nvm use 14

用nvm的好处就是可以灵活切换版本，版本不兼容的问题基本能迎刃而解。

依赖项问题处理

依赖问题通常分两种，一是缺失依赖，二是依赖冲突。

缺失依赖：运行时提示“Module not found”，比如Cannot find module 'express'，一般是因为项目依赖没装全。最干净的做法是进入项目根目录，先删掉旧的依赖和锁文件，再重新安装：

rm -rf node_modules package-lock.json  # 删除旧依赖和锁文件，避免缓存问题
npm install  # 重新安装所有依赖

依赖冲突：安装过程中间出现ERESOLVE unable to resolve dependency tree这类错误，通常是peer依赖版本不匹配。可以尝试用--legacy-peer-deps参数忽略冲突：

npm install --legacy-peer-deps

确保package.json里声明的依赖版本确实与应用兼容，这一点很重要。

端口占用问题

启动应用时遇到“Error: listen EADDRINUSE :::3000”，说明端口3000已经被占用了。解决思路很清晰：

• 先找到占用端口的进程：

  sudo lsof -i :3000  # 替换为实际端口号

• 拿到PID后，强制终止该进程：

  kill -9 

• 或者干脆改应用端口，比如从3000改成3001，避免冲突：

  const port = process.env.PORT || 3001;
  app.listen(port, () => console.log(`Server running on port ${port}`));

另外，也要注意检查一下Nginx、Apache这类服务是否占用了目标端口。

glibc版本过低

如果运行时报错“/lib64/libm.so.6: version `GLIBC_2.27' not found”，说明系统glibc版本太老，带不动当前Node.js版本。有两个思路：

• 升级glibc——但这事要谨慎操作，因为升级系统库可能影响整体稳定性：

  sudo yum update glibc  # 部分CentOS版本可能无法升级到所需版本

• 或者，用nvm安装一个兼容低版本glibc的Node.js，比如12.x：

  nvm install 12
  nvm use 12

实际来看，降级Node.js版本是更稳妥的做法。

权限问题

运行时报“Permission denied”，通常是因为应用没有权限访问某个文件或目录，或者试图绑定80这样的特权端口。解决方法：

• 调整文件/目录权限，给应用用户赋予合适的读写权限：

  chmod -R 755 /path/to/app  # 所有者读写执行，其他用户读执行
  chown -R nginx:nginx /path/to/app  # 根据实际用户调整

• 如果非要使用80端口，可以通过authbind工具来授权：

  sudo yum install authbind
  sudo touch /etc/authbind/byport/80
  sudo chmod 500 /etc/authbind/byport/80
  sudo chown  /etc/authbind/byport/80  # 为当前用户

  然后在代码中绑定80端口：

  app.listen(80, () => console.log('Server running on port 80'));

确保应用有足够的权限访问所需资源，这是基础前提。

日志分析

日志是定位错误的关键帮手。如果应用有配置日志文件，比如logs/error.log，可以用tail命令实时查看最新错误：

tail -f /path/to/app/logs/error.log

如果应用崩溃了且没有日志输出，那就去系统日志里找线索：

sudo journalctl -xe  # CentOS 7+
sudo tail -n 50 /var/log/messages  # CentOS 6

日志里通常藏着错误堆栈、触发时间以及具体原因，比如内存溢出、未捕获异常等。

代码调试

如果日志分析下来还是找不到问题根源，那就得用调试工具了。Node.js自带调试工具：

node inspect app.js

启动后，在Chrome浏览器中访问chrome://inspect，点击“Open dedicated DevTools for Node”就可以进行断点调试了。

也可以用Visual Studio Code的调试功能，配置好launch.json就行。另外，还有专门的Node.js调试工具ndb：

npm install -g ndb
ndb app.js

通过调试，语法错误、未捕获异常或逻辑问题都能快速定位。

使用进程管理工具

PM2是管理Node.js进程的利器，可以方便地启动、停止、重启应用，还能在应用崩溃后自动重启，并记录日志：

# 全局安装PM2
sudo npm install pm2 -g

# 启动应用（假设入口文件为app.js）
pm2 start app.js --name "my-app"

# 查看应用状态
pm2 list

# 查看应用日志
pm2 logs my-app

# 设置开机自启
pm2 startup
pm2 sa ve

PM2能有效避免因应用崩溃导致的服务中断，管理多个Node.js进程也很方便。算得上是生产环境的标配工具了。