【Node.js】process：掌控进程的“神经中枢”（二）

5.1 process.pid与process.ppid：进程的“身份证”#

• process.pid：当前进程的唯一 ID（PID），是进程在操作系统中的“身份证”；
• process.ppid：父进程的 ID（PPID），即启动当前进程的进程（如npm run start的父进程是npm）。

1
logger.info('服务启动成功', {
2
  pid: process.pid,
3
  ppid: process.ppid,
4
  port: 3000,
5
  env: process.env.NODE_ENV,
6
})

5.2 process.uptime()与process.hrtime()：时间的“高精度尺子”#

• process.uptime()：返回进程已运行的时间（秒），包含小数（如10.5秒表示运行了 10 秒+500 毫秒）；
• process.hrtime([time])：返回纳秒级的高精度时间，用于测量代码执行时间（如函数性能）。

1
// 记录开始时间（[秒, 纳秒]）
2
const start = process.hrtime()
3

4
// 执行要测量的函数（如 heavyComputation）
5
heavyComputation()
6

7
// 计算耗时
8
const [seconds, nanoseconds] = process.hrtime(start)
9
const milliseconds = seconds * 1000 + nanoseconds / 1e6 // 转换为毫秒
10

11
logger.info('函数执行时间', {
12
  function: 'heavyComputation',
13
  time: `${milliseconds.toFixed(2)}ms`,
14
})

5.3 process.memoryUsage()：内存的“体检报告”#

process.memoryUsage()返回当前进程的内存使用情况（字节），包含 4 个关键字段：

• rss（Resident Set Size）：进程占用的物理内存（即“常驻内存”）；
• heapTotal：V8 堆的总内存（包括已用和未用）；
• heapUsed：V8 堆的已用内存（业务代码占用的内存）；
• external：V8 外部的内存（如 Buffer 占用的内存）。

1
setInterval(() => {
2
  const memory = process.memoryUsage()
3
  logger.info('内存使用情况', {
4
    rss: `${(memory.rss / 1024 / 1024).toFixed(2)}MB`, // 转换为MB
5
    heapTotal: `${(memory.heapTotal / 1024 / 1024).toFixed(2)}MB`,
6
    heapUsed: `${(memory.heapUsed / 1024 / 1024).toFixed(2)}MB`,
7
    external: `${(memory.external / 1024 / 1024).toFixed(2)}MB`,
8
  })
9
}, 5000) // 每5秒记录一次

5.4 process.signal：处理操作系统信号#

操作系统会向进程发送信号（Signal），用于控制进程的生命周期（如终止、中断）。process可以通过on方法监听这些信号：

1
const express = require('express')
2
const app = express()
3
const server = app.listen(3000)
4

5
// 优雅关闭函数
6
const gracefulShutdown = () => {
7
  logger.info('开始优雅关闭服务')
8

9
  // 1. 关闭服务器，停止接受新请求
10
  server.close(async () => {
11
    logger.info('服务器已停止接受新请求')
12

13
    // 2. 清理资源（如关闭数据库、Redis）
14
    await Promise.all([dbClient.close(), redisClient.quit()])
15
    logger.info('资源清理完成')
16

17
    // 3. 退出进程（0表示正常退出）
18
    process.exit(0)
19
  })
20

21
  // 4. 超时强制退出（防止清理卡住）
22
  setTimeout(() => {
23
    logger.error('优雅关闭超时，强制退出')
24
    process.exit(1)
25
  }, 10000) // 10秒超时
26
}
27

28
// 监听优雅终止信号
29
process.on('SIGTERM', gracefulShutdown)
30
process.on('SIGINT', gracefulShutdown)

5.5 process.cwd()与process.chdir()：工作目录的“指南针”#

• process.cwd()：返回当前工作目录（CWD），即进程启动时的目录（如/home/user/project）；
• process.chdir(path)：改变当前工作目录到path（如process.chdir('./src')）。

1
const path = require('path')
2

3
// 正确：绝对路径（不受CWD影响）
4
const configPath = path.resolve(__dirname, 'config', 'prod.js')
5

6
// 错误：相对路径（依赖CWD）
7
const badConfigPath = './config/prod.js'

6.1 优雅关闭：避免中断用户请求#

如 5.4 节所述，优雅关闭是生产环境的必备能力。其核心逻辑是：

1. 监听SIGTERM和SIGINT信号；
2. 关闭服务器，停止接受新请求；
3. 清理资源（数据库、Redis、文件句柄）；
4. 退出进程。

6.2 监控：实时掌握进程状态#

生产环境中，监控是排查问题的关键。process的 API 可以帮助我们收集以下核心指标：

• 进程 ID（process.pid）；
• 运行时间（process.uptime()）；
• 内存使用（process.memoryUsage()）；
• CPU 使用（需结合os模块）。

1
const express = require('express')
2
const app = express()
3

4
// 暴露Prometheus指标
5
app.get('/metrics', (req, res) => {
6
  const memory = process.memoryUsage()
7
  const metrics = [
8
    // 进程ID
9
    `process_pid ${process.pid}`,
10
    // 运行时间（秒）
11
    `process_uptime ${process.uptime()}`,
12
    // 内存使用（字节）
13
    `process_memory_rss ${memory.rss}`,
14
    `process_memory_heap_total ${memory.heapTotal}`,
15
    `process_memory_heap_used ${memory.heapUsed}`,
16
    // CPU核心数（需os模块）
17
    `process_cpu_cores ${require('os').cpus().length}`,
18
  ]
19

20
  res.set('Content-Type', 'text/plain')
21
  res.send(metrics.join('\n'))
22
})
23

24
app.listen(3000)

6.3 多进程：利用多核 CPU#

Node.js 是单线程的，但可以通过cluster模块创建多进程，利用多核 CPU 提升性能。process的 API 可以帮助管理子进程：

1
const cluster = require('cluster')
2
const os = require('os')
3
const express = require('express')
4

5
if (cluster.isMaster) {
6
  // 主进程：创建子进程（数量等于CPU核心数）
7
  const numCPUs = os.cpus().length
8
  logger.info('主进程启动', {
9
    pid: process.pid,
10
    numWorkers: numCPUs,
11
  })
12

13
  // 启动子进程
14
  for (let i = 0; i < numCPUs; i++) {
15
    cluster.fork()
16
  }
17

18
  // 监听子进程退出，自动重启
19
  cluster.on('exit', (worker, code, signal) => {
20
    logger.error('子进程退出', {
21
      workerPid: worker.process.pid,
22
      code,
23
      signal,
24
    })
25
    cluster.fork() // 重启子进程
26
  })
27
} else {
28
  // 子进程：启动Express服务
29
  const app = express()
30
  app.get('/', (req, res) => {
31
    res.send(`Hello from worker ${process.pid}`)
32
  })
33
  app.listen(3000)
34
  logger.info('子进程启动', { pid: process.pid })
35
}

6.4 日志：记录所有关键信息#

在生产环境中，日志是排查问题的唯一依据。process的 API 可以为日志增加以下关键字段：

• 进程 ID（process.pid）；
• 环境变量（process.env.NODE_ENV）；
• 运行时间（process.uptime()）。

1
const winston = require('winston')
2
const { combine, timestamp, json, printf } = winston.format
3

4
// 自定义日志格式（包含process信息）
5
const customFormat = printf(({ level, message, timestamp, ...metadata }) => {
6
  return JSON.stringify({
7
    level,
8
    message,
9
    timestamp,
10
    pid: process.pid,
11
    env: process.env.NODE_ENV,
12
    ...metadata,
13
  })
14
})
15

16
const logger = winston.createLogger({
17
  level: 'info',
18
  format: combine(timestamp(), customFormat),
19
  transports: [
20
    new winston.transports.File({ filename: 'combined.log' }),
21
    new winston.transports.Console(),
22
  ],
23
})
24

25
// 使用日志
26
logger.info('服务启动成功', { port: 3000 })
27
logger.error('数据库连接失败', { error: err.message })

8.1 问题 1：process.env 读取不到环境变量#

现象：process.env.DB_HOST返回undefined，但环境变量已设置。
原因：

• 环境变量未正确加载（如.env文件未被dotenv加载）；
• 环境变量的大小写错误（Linux/macOS 区分大小写）；
• 生产环境未设置环境变量（如 Docker 未通过-e传递）。
  解决方案：

1. 检查.env文件路径是否正确，确保dotenv.config()在入口文件顶部调用；
2. 统一环境变量的大小写（如用DB_HOST代替db_host）；
3. 生产环境中，通过部署平台的环境变量设置功能（如 Docker 的env_file）传递变量。

8.2 问题 2：uncaughtException 未触发#

现象：同步代码抛出异常，但process.on('uncaughtException')未捕获。
原因：

• 异常被try/catch捕获（uncaughtException只处理未捕获的异常）；
• process._fatalException被修改（如被第三方库覆盖）；
• Node.js 版本问题（如 v16 以下的版本对uncaughtException的处理不同）。
  解决方案：

1. 检查代码中是否有try/catch捕获了异常；
2. 打印process._fatalException，确保它是 Node.js 的默认函数（正常情况下是[Function: onGlobalUncaughtException]）；
3. 升级 Node.js 到 v18 及以上版本（获得更稳定的异常处理）。

8.3 问题 3：优雅关闭失败，进程直接退出#

现象：发送SIGTERM信号后，进程未清理资源就直接退出。
原因：

• 未监听SIGTERM或SIGINT信号；
• 清理资源的异步操作未完成（如数据库连接未关闭）；
• 超时时间设置过短（如 5 秒超时，但清理需要 10 秒）。
  解决方案：

1. 确保监听了SIGTERM和SIGINT信号（如process.on('SIGTERM', gracefulShutdown)）；
2. 使用async/await等待清理操作完成（如await dbClient.close()）；
3. 延长超时时间（如设置为 10 秒），给清理操作足够的时间。

8.4 问题 4：process.chdir 导致路径错误#

现象：require('./config')报错Cannot find module，但文件存在。
原因：process.chdir改变了当前工作目录（CWD），导致相对路径失效（如process.chdir('./src')后，./config的路径变为/home/user/project/src/config，而实际路径是/home/user/project/config）。
解决方案：

• 永远不要使用process.chdir()（它改变全局状态，容易导致路径错误）；
• 用path.resolve(__dirname, 'path')获取绝对路径（不依赖 CWD），例如：

  1
  const path = require('path')
  2
  const configPath = path.resolve(__dirname, 'config', 'prod.js') // 正确的绝对路径

8.5 问题 5：process.exit 导致异步操作中断#

现象：process.exit(1)调用后，文件写入或数据库操作未完成（如fs.writeFile的回调未执行）。
原因：process.exit是同步操作，会立即终止进程，中断所有未完成的异步操作（包括微任务和宏任务）。
解决方案：

• 避免使用process.exit()（除非遇到致命错误）；
• 让进程自然退出（当事件循环中没有待处理的任务时，进程会自动退出）；
• 若必须退出，使用beforeExit事件执行清理操作（beforeExit会等待异步操作完成）：

  1
  process.on('beforeExit', async () => {
  2
    await dbClient.close() // 等待数据库连接关闭
  3
    await fs.promises.writeFile('log.txt', 'exit') // 等待文件写入
  4
    process.exit(0)
  5
  })

9.1 ShadowRealm 的支持#

Node.js 正在推进ShadowRealm的支持（由 Node.js TSC 成员吞吞主导）。ShadowRealm 允许创建隔离的运行环境，每个 ShadowRealm 有自己的process对象。未来，process的初始化将更灵活，支持多 Realm 的场景：

• 隔离不可信代码（如插件系统中的第三方代码）；
• 实现多租户应用（每个租户有独立的process对象）。

9.2 更完善的优雅关闭 API#

Node.js 18+版本中，process新增了process.off('SIGTERM', handler)等方法，简化了信号的管理。未来，可能会推出更高级的优雅关闭 API（如process.gracefulShutdown()），减少开发者的 boilerplate 代码：

1
// 未来可能的API：一键优雅关闭
2
process.gracefulShutdown({
3
  timeout: 10000, // 超时时间
4
  cleanup: async () => {
5
    await dbClient.close()
6
    await redisClient.quit()
7
  },
8
})

9.3 更丰富的监控指标#

随着process.memoryUsage()和process.cpuUsage()的改进，未来process可能会提供更丰富的监控指标：

• GPU 使用情况（process.gpuUsage()）；
• 网络 IO 统计（process.networkUsage()）；
• 文件句柄数（process.fileDescriptors()）。
  这些指标将为开发者提供更全面的进程状态信息，帮助快速定位性能问题（如内存泄漏、文件句柄泄漏）。

9.4 与 Web 标准的对齐#

Node.js 正在努力与 Web 标准对齐（如globalThis的支持）。未来，process的 API 可能会更接近 Web 标准（如navigator对象），减少前端开发者的学习成本：

• process.platform可能会更名为navigator.platform（与浏览器对齐）；
• process.env可能会更接近window.env（前端常用的环境变量管理方式）。