Prozess

Das process-Objekt bietet Informationen über den aktuellen Node.js-Prozess und Kontrolle darüber.

ESMCJS

import process from 'node:process'

const process = require('node:process')

Prozessereignisse

Das process-Objekt ist eine Instanz von EventEmitter.

Ereignis: `'beforeExit'`

Hinzugefügt in: v0.11.12

Das Ereignis 'beforeExit' wird ausgelöst, wenn Node.js seine Ereignisschleife leert und keine zusätzliche Arbeit zu planen hat. Normalerweise beendet sich der Node.js-Prozess, wenn keine Arbeit geplant ist, aber ein Listener, der für das 'beforeExit'-Ereignis registriert ist, kann asynchrone Aufrufe tätigen und dadurch bewirken, dass der Node.js-Prozess fortgesetzt wird.

Die Listener-Callback-Funktion wird mit dem Wert von process.exitCode als einzigem Argument aufgerufen.

Das Ereignis 'beforeExit' wird nicht unter Bedingungen ausgelöst, die eine explizite Beendigung verursachen, z. B. durch Aufruf von process.exit() oder nicht abgefangene Ausnahmen.

Das Ereignis 'beforeExit' sollte nicht als Alternative zum Ereignis 'exit' verwendet werden, es sei denn, es ist beabsichtigt, zusätzliche Arbeit zu planen.

ESMCJS

import process from 'node:process'

process.on('beforeExit', code => {
  console.log('Prozess beforeExit-Ereignis mit Code: ', code)
})

process.on('exit', code => {
  console.log('Prozess exit-Ereignis mit Code: ', code)
})

console.log('Diese Nachricht wird zuerst angezeigt.')

// Gibt aus:
// Diese Nachricht wird zuerst angezeigt.
// Prozess beforeExit-Ereignis mit Code: 0
// Prozess exit-Ereignis mit Code: 0

const process = require('node:process')

process.on('beforeExit', code => {
  console.log('Prozess beforeExit-Ereignis mit Code: ', code)
})

process.on('exit', code => {
  console.log('Prozess exit-Ereignis mit Code: ', code)
})

console.log('Diese Nachricht wird zuerst angezeigt.')

// Gibt aus:
// Diese Nachricht wird zuerst angezeigt.
// Prozess beforeExit-Ereignis mit Code: 0
// Prozess exit-Ereignis mit Code: 0

Ereignis: `'disconnect'`

Hinzugefügt in: v0.7.7

Wenn der Node.js-Prozess mit einem IPC-Kanal gestartet wird (siehe die Dokumentation Child Process und Cluster), wird das 'disconnect'-Ereignis ausgelöst, wenn der IPC-Kanal geschlossen wird.

Ereignis: `'exit'`

Hinzugefügt in: v0.1.7

code <integer>

Das 'exit'-Ereignis wird ausgelöst, wenn der Node.js-Prozess kurz vor dem Beenden steht, entweder als Folge von:

Der explizite Aufruf der process.exit()-Methode;
Die Node.js-Event-Loop hat keine zusätzlichen Aufgaben mehr zu erledigen.

Es gibt keine Möglichkeit, das Beenden der Event-Loop an dieser Stelle zu verhindern, und sobald alle 'exit'-Listener ihre Ausführung beendet haben, wird der Node.js-Prozess beendet.

Die Listener-Callback-Funktion wird mit dem Exit-Code aufgerufen, der entweder durch die Eigenschaft process.exitCode oder das exitCode-Argument angegeben wird, das an die Methode process.exit() übergeben wird.

ESMCJS

import process from 'node:process'

process.on('exit', code => {
  console.log(`Wird mit Code beendet: ${code}`)
})

const process = require('node:process')

process.on('exit', code => {
  console.log(`Wird mit Code beendet: ${code}`)
})

Listener-Funktionen müssen nur synchrone Operationen ausführen. Der Node.js-Prozess wird unmittelbar nach dem Aufruf der 'exit'-Ereignislistener beendet, wodurch alle zusätzlichen Arbeiten, die noch in der Event-Loop anstehen, abgebrochen werden. Im folgenden Beispiel wird beispielsweise das Timeout niemals eintreten:

ESMCJS

import process from 'node:process'

process.on('exit', code => {
  setTimeout(() => {
    console.log('Dies wird nicht ausgeführt')
  }, 0)
})

const process = require('node:process')

process.on('exit', code => {
  setTimeout(() => {
    console.log('Dies wird nicht ausgeführt')
  }, 0)
})

Ereignis: `'message'`

Hinzugefügt in: v0.5.10

message <Object> | <boolean> | <number> | <string> | <null> ein geparstes JSON-Objekt oder ein serialisierbarer primitiver Wert.
sendHandle <net.Server> | <net.Socket> ein net.Server oder net.Socket Objekt, oder undefiniert.

Wenn der Node.js-Prozess mit einem IPC-Kanal erzeugt wird (siehe die Child Process und Cluster Dokumentation), wird das 'message' Ereignis immer dann ausgelöst, wenn eine Nachricht, die von einem übergeordneten Prozess mit childprocess.send() gesendet wurde, vom untergeordneten Prozess empfangen wird.

Die Nachricht durchläuft die Serialisierung und das Parsen. Die resultierende Nachricht ist möglicherweise nicht die gleiche wie die ursprünglich gesendete.

Wenn die Option serialization auf advanced gesetzt wurde, als der Prozess erzeugt wurde, kann das Argument message Daten enthalten, die JSON nicht darstellen kann. Siehe Erweiterte Serialisierung für child_process für weitere Details.

Ereignis: `'multipleResolves'`

Hinzugefügt in: v10.12.0

Veraltet seit: v17.6.0, v16.15.0

[Stabil: 0 - Veraltet]

Stabil: 0 Stabilität: 0 - Veraltet

type <string> Der Auflösungstyp. Einer von 'resolve' oder 'reject'.
promise <Promise> Das Promise, das mehr als einmal aufgelöst oder abgelehnt wurde.
value <any> Der Wert, mit dem das Promise nach der ursprünglichen Auflösung entweder aufgelöst oder abgelehnt wurde.

Das 'multipleResolves' Ereignis wird ausgelöst, wenn ein Promise entweder:

Mehr als einmal aufgelöst wurde.
Mehr als einmal abgelehnt wurde.
Nach dem Auflösen abgelehnt wurde.
Nach dem Ablehnen aufgelöst wurde.

Dies ist nützlich, um potenzielle Fehler in einer Anwendung zu verfolgen, während der Promise Konstruktor verwendet wird, da mehrere Auflösungen stillschweigend verschluckt werden. Das Auftreten dieses Ereignisses deutet jedoch nicht unbedingt auf einen Fehler hin. Zum Beispiel kann Promise.race() ein 'multipleResolves' Ereignis auslösen.

Aufgrund der Unzuverlässigkeit des Ereignisses in Fällen wie dem obigen Beispiel Promise.race() ist es veraltet.

ESMCJS

import process from 'node:process'

process.on('multipleResolves', (type, promise, reason) => {
  console.error(type, promise, reason)
  setImmediate(() => process.exit(1))
})

async function main() {
  try {
    return await new Promise((resolve, reject) => {
      resolve('First call')
      resolve('Swallowed resolve')
      reject(new Error('Swallowed reject'))
    })
  } catch {
    throw new Error('Failed')
  }
}

main().then(console.log)
// resolve: Promise { 'First call' } 'Swallowed resolve'
// reject: Promise { 'First call' } Error: Swallowed reject
//     at Promise (*)
//     at new Promise (<anonymous>)
//     at main (*)
// First call

const process = require('node:process')

process.on('multipleResolves', (type, promise, reason) => {
  console.error(type, promise, reason)
  setImmediate(() => process.exit(1))
})

async function main() {
  try {
    return await new Promise((resolve, reject) => {
      resolve('First call')
      resolve('Swallowed resolve')
      reject(new Error('Swallowed reject'))
    })
  } catch {
    throw new Error('Failed')
  }
}

main().then(console.log)
// resolve: Promise { 'First call' } 'Swallowed resolve'
// reject: Promise { 'First call' } Error: Swallowed reject
//     at Promise (*)
//     at new Promise (<anonymous>)
//     at main (*)
// First call

Ereignis: `'rejectionHandled'`

Hinzugefügt in: v1.4.1

promise <Promise> Das später behandelte Promise.

Das 'rejectionHandled' Ereignis wird ausgelöst, wenn ein Promise abgelehnt wurde und ein Fehlerhandler daran angehängt wurde (zum Beispiel mit promise.catch()), später als eine Runde der Node.js-Ereignisschleife.

Das Promise-Objekt wäre zuvor in einem 'unhandledRejection'-Ereignis ausgegeben worden, erhielt aber im Laufe der Verarbeitung einen Ablehnungs-Handler.

Es gibt keine Vorstellung von einer obersten Ebene für eine Promise-Kette, in der Ablehnungen immer behandelt werden können. Aufgrund ihrer inhärent asynchronen Natur kann eine Promise-Ablehnung zu einem späteren Zeitpunkt behandelt werden, möglicherweise viel später als der Ereignisschleifenzyklus, der für die Auslösung des 'unhandledRejection'-Ereignisses benötigt wird.

Eine andere Möglichkeit, dies auszudrücken, ist, dass es im Gegensatz zu synchronem Code, wo es eine ständig wachsende Liste von unbehandelten Ausnahmen gibt, bei Promises eine wachsende und schrumpfende Liste von unbehandelten Ablehnungen geben kann.

In synchronem Code wird das 'uncaughtException'-Ereignis ausgelöst, wenn die Liste der unbehandelten Ausnahmen wächst.

In asynchronem Code wird das 'unhandledRejection'-Ereignis ausgelöst, wenn die Liste der unbehandelten Ablehnungen wächst, und das 'rejectionHandled'-Ereignis wird ausgelöst, wenn die Liste der unbehandelten Ablehnungen schrumpft.

ESMCJS

import process from 'node:process'

const unhandledRejections = new Map()
process.on('unhandledRejection', (reason, promise) => {
  unhandledRejections.set(promise, reason)
})
process.on('rejectionHandled', promise => {
  unhandledRejections.delete(promise)
})

const process = require('node:process')

const unhandledRejections = new Map()
process.on('unhandledRejection', (reason, promise) => {
  unhandledRejections.set(promise, reason)
})
process.on('rejectionHandled', promise => {
  unhandledRejections.delete(promise)
})

In diesem Beispiel wächst und schrumpft die unhandledRejections-Map im Laufe der Zeit und spiegelt Ablehnungen wider, die zunächst unbehandelt sind und dann behandelt werden. Es ist möglich, solche Fehler in einem Fehlerprotokoll aufzuzeichnen, entweder regelmäßig (was wahrscheinlich am besten für langlaufende Anwendungen geeignet ist) oder beim Beenden des Prozesses (was wahrscheinlich am praktischsten für Skripte ist).

Ereignis: `'workerMessage'`

Hinzugefügt in: v22.5.0

value <any> Ein Wert, der mit postMessageToThread() übertragen wurde.
source <number> Die ID des sendenden Worker-Threads oder 0 für den Hauptthread.

Das 'workerMessage'-Ereignis wird für jede eingehende Nachricht ausgelöst, die von der anderen Partei mit postMessageToThread() gesendet wurde.

Ereignis: `'uncaughtException'`

[Verlauf]

Version	Änderungen
v12.0.0, v10.17.0	Das `origin`-Argument wurde hinzugefügt.
v0.1.18	Hinzugefügt in: v0.1.18

err <Error> Die nicht abgefangene Ausnahme.
origin <string> Gibt an, ob die Ausnahme von einer unbehandelten Ablehnung oder von einem synchronen Fehler stammt. Kann entweder 'uncaughtException' oder 'unhandledRejection' sein. Letzteres wird verwendet, wenn eine Ausnahme in einem Promise-basierten asynchronen Kontext auftritt (oder wenn ein Promise abgelehnt wird) und das Flag --unhandled-rejections auf strict oder throw gesetzt ist (was der Standard ist) und die Ablehnung nicht behandelt wird, oder wenn eine Ablehnung während der statischen Ladephase des ES-Moduls des Befehlszeilen-Einstiegspunkts auftritt.

Das 'uncaughtException'-Ereignis wird ausgelöst, wenn eine nicht abgefangene JavaScript-Ausnahme bis zur Ereignisschleife zurückblubbert. Standardmäßig behandelt Node.js solche Ausnahmen, indem es den Stack-Trace auf stderr ausgibt und mit dem Code 1 beendet, wodurch alle zuvor gesetzten process.exitCode überschrieben werden. Das Hinzufügen eines Handlers für das 'uncaughtException'-Ereignis überschreibt dieses Standardverhalten. Alternativ können Sie den process.exitCode im 'uncaughtException'-Handler ändern, was dazu führt, dass der Prozess mit dem angegebenen Exit-Code beendet wird. Andernfalls beendet sich der Prozess in Anwesenheit eines solchen Handlers mit 0.

ESMCJS

import process from 'node:process'
import fs from 'node:fs'

process.on('uncaughtException', (err, origin) => {
  fs.writeSync(process.stderr.fd, `Abgefangene Ausnahme: ${err}\n` + `Ausnahmeherkunft: ${origin}\n`)
})

setTimeout(() => {
  console.log('Das wird immer noch ausgeführt.')
}, 500)

// Absichtlich eine Ausnahme verursachen, aber nicht abfangen.
nonexistentFunc()
console.log('Das wird nicht ausgeführt.')

const process = require('node:process')
const fs = require('node:fs')

process.on('uncaughtException', (err, origin) => {
  fs.writeSync(process.stderr.fd, `Abgefangene Ausnahme: ${err}\n` + `Ausnahmeherkunft: ${origin}\n`)
})

setTimeout(() => {
  console.log('Das wird immer noch ausgeführt.')
}, 500)

// Absichtlich eine Ausnahme verursachen, aber nicht abfangen.
nonexistentFunc()
console.log('Das wird nicht ausgeführt.')

Es ist möglich, 'uncaughtException'-Ereignisse zu überwachen, ohne das Standardverhalten zum Beenden des Prozesses zu überschreiben, indem ein 'uncaughtExceptionMonitor'-Listener installiert wird.

Warnung: `'uncaughtException'` korrekt verwenden

'uncaughtException' ist ein grober Mechanismus zur Ausnahmebehandlung, der nur als letztes Mittel verwendet werden sollte. Das Ereignis sollte nicht als Äquivalent zu On Error Resume Next verwendet werden. Unbehandelte Ausnahmen bedeuten inhärent, dass sich eine Anwendung in einem undefinierten Zustand befindet. Der Versuch, den Anwendungscode fortzusetzen, ohne sich ordnungsgemäß von der Ausnahme zu erholen, kann zusätzliche unvorhergesehene und unvorhersehbare Probleme verursachen.

Ausnahmen, die innerhalb des Ereignishandlers ausgelöst werden, werden nicht abgefangen. Stattdessen wird der Prozess mit einem Exit-Code ungleich Null beendet und der Stack-Trace wird ausgegeben. Dies dient dazu, eine Endlosrekursion zu vermeiden.

Der Versuch, den normalen Betrieb nach einer nicht abgefangenen Ausnahme fortzusetzen, kann mit dem Ziehen des Netzsteckers beim Aufrüsten eines Computers verglichen werden. Neun von zehn Malen passiert nichts. Aber beim zehnten Mal wird das System beschädigt.

Die korrekte Verwendung von 'uncaughtException' besteht darin, eine synchrone Bereinigung der zugewiesenen Ressourcen (z. B. Dateideskriptoren, Handles usw.) durchzuführen, bevor der Prozess heruntergefahren wird. Es ist nicht sicher, den normalen Betrieb nach 'uncaughtException' fortzusetzen.

Um eine abgestürzte Anwendung auf zuverlässigere Weise neu zu starten, unabhängig davon, ob 'uncaughtException' ausgelöst wird oder nicht, sollte ein externer Monitor in einem separaten Prozess eingesetzt werden, um Anwendungsfehler zu erkennen und diese bei Bedarf wiederherzustellen oder neu zu starten.

Ereignis: `'uncaughtExceptionMonitor'`

Hinzugefügt in: v13.7.0, v12.17.0

err <Error> Die nicht abgefangene Ausnahme.
origin <string> Gibt an, ob die Ausnahme von einer unbehandelten Ablehnung oder von synchronen Fehlern stammt. Kann entweder 'uncaughtException' oder 'unhandledRejection' sein. Letzteres wird verwendet, wenn eine Ausnahme in einem Promise-basierten asynchronen Kontext auftritt (oder wenn ein Promise abgelehnt wird) und das Flag --unhandled-rejections auf strict oder throw (was die Standardeinstellung ist) gesetzt ist und die Ablehnung nicht behandelt wird, oder wenn eine Ablehnung während der statischen Ladephase des ES-Moduls des Befehlszeileneinstiegspunkts auftritt.

Das Ereignis 'uncaughtExceptionMonitor' wird ausgelöst, bevor ein Ereignis 'uncaughtException' ausgelöst wird oder ein Hook, der über process.setUncaughtExceptionCaptureCallback() installiert wurde, aufgerufen wird.

Das Installieren eines 'uncaughtExceptionMonitor'-Listeners ändert nichts am Verhalten, sobald ein 'uncaughtException'-Ereignis ausgelöst wird. Der Prozess stürzt weiterhin ab, wenn kein 'uncaughtException'-Listener installiert ist.

ESMCJS

import process from 'node:process'

process.on('uncaughtExceptionMonitor', (err, origin) => {
  MyMonitoringTool.logSync(err, origin)
})

// Verursachen Sie absichtlich eine Ausnahme, fangen Sie sie aber nicht ab.
nonexistentFunc()
// Stürzt Node.js immer noch ab

const process = require('node:process')

process.on('uncaughtExceptionMonitor', (err, origin) => {
  MyMonitoringTool.logSync(err, origin)
})

// Verursachen Sie absichtlich eine Ausnahme, fangen Sie sie aber nicht ab.
nonexistentFunc()
// Stürzt Node.js immer noch ab

Ereignis: `'unhandledRejection'`

[Verlauf]

Version	Änderungen
v7.0.0	Das Nicht-Behandeln von `Promise`-Ablehnungen ist veraltet.
v6.6.0	Nicht behandelte `Promise`-Ablehnungen geben jetzt eine Prozesswarnung aus.
v1.4.1	Hinzugefügt in: v1.4.1

reason <Error> | <any> Das Objekt, mit dem das Promise abgelehnt wurde (typischerweise ein Error-Objekt).
promise <Promise> Das abgelehnte Promise.

Das 'unhandledRejection'-Ereignis wird immer dann ausgelöst, wenn ein Promise abgelehnt wird und innerhalb einer Runde der Ereignisschleife kein Fehlerbehandler an das Promise angehängt ist. Bei der Programmierung mit Promises werden Ausnahmen als "abgelehnte Promises" gekapselt. Ablehnungen können mit promise.catch() abgefangen und behandelt werden und werden durch eine Promise-Kette weitergegeben. Das 'unhandledRejection'-Ereignis ist nützlich, um Promises zu erkennen und zu verfolgen, die abgelehnt wurden, deren Ablehnungen aber noch nicht behandelt wurden.

ESMCJS

import process from 'node:process'

process.on('unhandledRejection', (reason, promise) => {
  console.log('Nicht behandelte Ablehnung bei:', promise, 'Grund:', reason)
  // Anwendungsspezifische Protokollierung, Auslösen eines Fehlers oder andere Logik hier
})

somePromise.then(res => {
  return reportToUser(JSON.pasre(res)) // Beachten Sie den Tippfehler (`pasre`)
}) // Kein `.catch()` oder `.then()`

const process = require('node:process')

process.on('unhandledRejection', (reason, promise) => {
  console.log('Nicht behandelte Ablehnung bei:', promise, 'Grund:', reason)
  // Anwendungsspezifische Protokollierung, Auslösen eines Fehlers oder andere Logik hier
})

somePromise.then(res => {
  return reportToUser(JSON.pasre(res)) // Beachten Sie den Tippfehler (`pasre`)
}) // Kein `.catch()` oder `.then()`

Das Folgende wird auch das Auslösen des 'unhandledRejection'-Ereignisses bewirken:

ESMCJS

import process from 'node:process'

function SomeResource() {
  // Setzen Sie den geladenen Status anfänglich auf ein abgelehntes Promise
  this.loaded = Promise.reject(new Error('Ressource noch nicht geladen!'))
}

const resource = new SomeResource()
// kein .catch oder .then auf resource.loaded für mindestens eine Runde

const process = require('node:process')

function SomeResource() {
  // Setzen Sie den geladenen Status anfänglich auf ein abgelehntes Promise
  this.loaded = Promise.reject(new Error('Ressource noch nicht geladen!'))
}

const resource = new SomeResource()
// kein .catch oder .then auf resource.loaded für mindestens eine Runde

In diesem Beispielfall ist es möglich, die Ablehnung als Entwicklerfehler zu verfolgen, wie es typischerweise bei anderen 'unhandledRejection'-Ereignissen der Fall wäre. Um solche Fehler zu beheben, kann ein nicht-operativer .catch(() => { })-Handler an resource.loaded angehängt werden, wodurch das Auslösen des 'unhandledRejection'-Ereignisses verhindert würde.

Ereignis: `'warning'`

Hinzugefügt in: v6.0.0

warning <Error> Schlüsseleigenschaften der Warnung sind:
- name <string> Der Name der Warnung. Standard: 'Warning'.
- message <string> Eine vom System bereitgestellte Beschreibung der Warnung.
- stack <string> Ein Stack-Trace zu der Stelle im Code, an der die Warnung ausgegeben wurde.

Das 'warning'-Ereignis wird immer dann ausgelöst, wenn Node.js eine Prozesswarnung ausgibt.

Eine Prozesswarnung ähnelt einem Fehler insofern, als sie außergewöhnliche Bedingungen beschreibt, die dem Benutzer zur Kenntnis gebracht werden. Warnungen sind jedoch nicht Teil des normalen Node.js- und JavaScript-Fehlerbehandlungsflusses. Node.js kann Warnungen ausgeben, wenn es schlechte Codierungspraktiken erkennt, die zu suboptimaler Anwendungsleistung, Fehlern oder Sicherheitslücken führen könnten.

ESMCJS

import process from 'node:process'

process.on('warning', warning => {
  console.warn(warning.name) // Den Warnungsnamen ausgeben
  console.warn(warning.message) // Die Warnmeldung ausgeben
  console.warn(warning.stack) // Den Stack-Trace ausgeben
})

const process = require('node:process')

process.on('warning', warning => {
  console.warn(warning.name) // Den Warnungsnamen ausgeben
  console.warn(warning.message) // Die Warnmeldung ausgeben
  console.warn(warning.stack) // Den Stack-Trace ausgeben
})

Standardmäßig gibt Node.js Prozesswarnungen an stderr aus. Die Befehlszeilenoption --no-warnings kann verwendet werden, um die Standardkonsolenausgabe zu unterdrücken, aber das 'warning'-Ereignis wird weiterhin vom process-Objekt ausgelöst. Derzeit ist es nicht möglich, bestimmte Warnungstypen außer Veraltungswarnungen zu unterdrücken. Um Veraltungswarnungen zu unterdrücken, siehe das Flag --no-deprecation.

Das folgende Beispiel veranschaulicht die Warnung, die an stderr ausgegeben wird, wenn zu viele Listener zu einem Ereignis hinzugefügt wurden:

bash

$ node
> events.defaultMaxListeners = 1;
> process.on('foo', () => {});
> process.on('foo', () => {});
> (node:38638) MaxListenersExceededWarning: Mögliches Speicherleck durch EventEmitter festgestellt. 2 foo-Listener hinzugefügt. Verwenden Sie emitter.setMaxListeners(), um das Limit zu erhöhen.

Im Gegensatz dazu schaltet das folgende Beispiel die Standardwarnungsausgabe ab und fügt einen benutzerdefinierten Handler zum 'warning'-Ereignis hinzu:

bash

$ node --no-warnings
> const p = process.on('warning', (warning) => console.warn('Tut das nicht!'));
> events.defaultMaxListeners = 1;
> process.on('foo', () => {});
> process.on('foo', () => {});
> Tut das nicht!

Die Befehlszeilenoption --trace-warnings kann verwendet werden, um die vollständige Stack-Trace der Warnung in die Standardkonsolenausgabe für Warnungen aufzunehmen.

Das Starten von Node.js mit dem Befehlszeilenflag --throw-deprecation führt dazu, dass benutzerdefinierte Veraltungswarnungen als Ausnahmen ausgelöst werden.

Die Verwendung des Befehlszeilenflags --trace-deprecation bewirkt, dass die benutzerdefinierte Veraltung zusammen mit dem Stack-Trace an stderr ausgegeben wird.

Die Verwendung des Befehlszeilenflags --no-deprecation unterdrückt alle Meldungen der benutzerdefinierten Veraltung.

Die Befehlszeilenflags *-deprecation wirken sich nur auf Warnungen aus, die den Namen 'DeprecationWarning' verwenden.

Benutzerdefinierte Warnungen ausgeben

Siehe die process.emitWarning()-Methode zum Ausgeben benutzerdefinierter oder anwendungsspezifischer Warnungen.

Node.js-Warnungsnamen

Es gibt keine strengen Richtlinien für Warnungstypen (wie durch die Eigenschaft name identifiziert), die von Node.js ausgegeben werden. Neue Warnungstypen können jederzeit hinzugefügt werden. Einige der häufigsten Warnungstypen sind:

'DeprecationWarning' - Zeigt die Verwendung einer veralteten Node.js-API oder -Funktion an. Solche Warnungen müssen eine 'code'-Eigenschaft enthalten, die den Veraltungscode identifiziert.
'ExperimentalWarning' - Zeigt die Verwendung einer experimentellen Node.js-API oder -Funktion an. Solche Funktionen müssen mit Vorsicht verwendet werden, da sie sich jederzeit ändern können und nicht denselben strengen semantischen Versions- und langfristigen Supportrichtlinien wie unterstützte Funktionen unterliegen.
'MaxListenersExceededWarning' - Zeigt an, dass zu viele Listener für ein bestimmtes Ereignis entweder auf einem EventEmitter oder EventTarget registriert wurden. Dies ist oft ein Hinweis auf ein Speicherleck.
'TimeoutOverflowWarning' - Zeigt an, dass ein numerischer Wert, der nicht in eine 32-Bit-Ganzzahl mit Vorzeichen passt, entweder an die Funktionen setTimeout() oder setInterval() übergeben wurde.
'TimeoutNegativeWarning' - Zeigt an, dass eine negative Zahl entweder an die Funktionen setTimeout() oder setInterval() übergeben wurde.
'TimeoutNaNWarning' - Zeigt an, dass ein Wert, der keine Zahl ist, entweder an die Funktionen setTimeout() oder setInterval() übergeben wurde.
'UnsupportedWarning' - Zeigt die Verwendung einer nicht unterstützten Option oder Funktion an, die ignoriert und nicht als Fehler behandelt wird. Ein Beispiel ist die Verwendung der HTTP-Antwortstatusmeldung bei Verwendung der HTTP/2-Kompatibilitäts-API.

Ereignis: `'worker'`

Hinzugefügt in: v16.2.0, v14.18.0

worker <Worker> Der erstellte <Worker>.

Das 'worker'-Ereignis wird ausgelöst, nachdem ein neuer <Worker>-Thread erstellt wurde.

Signalereignisse

Signalereignisse werden ausgelöst, wenn der Node.js-Prozess ein Signal empfängt. Eine Auflistung der standardmäßigen POSIX-Signalnamen wie 'SIGINT', 'SIGHUP' usw. finden Sie in signal(7).

Signale sind in Worker-Threads nicht verfügbar.

Der Signalhandler empfängt den Namen des Signals ('SIGINT', 'SIGTERM' usw.) als erstes Argument.

Der Name jedes Ereignisses ist der übliche Name des Signals in Großbuchstaben (z. B. 'SIGINT' für SIGINT-Signale).

ESMCJS

import process from 'node:process'

// Beginnen Sie mit dem Lesen von stdin, damit der Prozess nicht beendet wird.
process.stdin.resume()

process.on('SIGINT', () => {
  console.log('SIGINT empfangen. Drücken Sie Control-D zum Beenden.')
})

// Verwenden einer einzelnen Funktion zur Behandlung mehrerer Signale
function handle(signal) {
  console.log(`Empfangen ${signal}`)
}

process.on('SIGINT', handle)
process.on('SIGTERM', handle)

const process = require('node:process')

// Beginnen Sie mit dem Lesen von stdin, damit der Prozess nicht beendet wird.
process.stdin.resume()

process.on('SIGINT', () => {
  console.log('SIGINT empfangen. Drücken Sie Control-D zum Beenden.')
})

// Verwenden einer einzelnen Funktion zur Behandlung mehrerer Signale
function handle(signal) {
  console.log(`Empfangen ${signal}`)
}

process.on('SIGINT', handle)
process.on('SIGTERM', handle)

'SIGUSR1' wird von Node.js reserviert, um den Debugger zu starten. Es ist möglich, einen Listener zu installieren, dies kann jedoch den Debugger beeinträchtigen.
'SIGTERM' und 'SIGINT' haben auf Nicht-Windows-Plattformen Standardhandler, die den Terminalmodus zurücksetzen, bevor sie mit dem Code 128 + Signalnummer beendet werden. Wenn eines dieser Signale einen installierten Listener hat, wird sein Standardverhalten entfernt (Node.js wird nicht mehr beendet).
'SIGPIPE' wird standardmäßig ignoriert. Es kann ein Listener installiert werden.
'SIGHUP' wird unter Windows generiert, wenn das Konsolenfenster geschlossen wird, und auf anderen Plattformen unter verschiedenen ähnlichen Bedingungen. Siehe signal(7). Es kann ein Listener installiert werden, Node.js wird jedoch unter Windows etwa 10 Sekunden später bedingungslos beendet. Auf Nicht-Windows-Plattformen ist das Standardverhalten von SIGHUP das Beenden von Node.js, aber sobald ein Listener installiert wurde, wird sein Standardverhalten entfernt.
'SIGTERM' wird unter Windows nicht unterstützt, es kann jedoch abgehört werden.
'SIGINT' vom Terminal wird auf allen Plattformen unterstützt und kann normalerweise mit + generiert werden (dies kann jedoch konfigurierbar sein). Es wird nicht generiert, wenn der Terminal-Raw-Modus aktiviert ist und + verwendet wird.
'SIGBREAK' wird unter Windows geliefert, wenn + gedrückt wird. Auf Nicht-Windows-Plattformen kann es abgehört werden, es gibt jedoch keine Möglichkeit, es zu senden oder zu generieren.
'SIGWINCH' wird geliefert, wenn die Konsolengröße geändert wurde. Unter Windows geschieht dies nur beim Schreiben in die Konsole, wenn der Cursor bewegt wird oder wenn ein lesbares TTY im Raw-Modus verwendet wird.
'SIGKILL' kann keinen Listener installiert haben, es wird Node.js auf allen Plattformen bedingungslos beenden.
'SIGSTOP' kann keinen Listener installiert haben.
'SIGBUS', 'SIGFPE', 'SIGSEGV' und 'SIGILL' hinterlassen den Prozess, wenn sie nicht künstlich mit kill(2) ausgelöst werden, in einem Zustand, in dem es nicht sicher ist, JS-Listener aufzurufen. Dies kann dazu führen, dass der Prozess nicht mehr reagiert.
0 kann gesendet werden, um die Existenz eines Prozesses zu testen. Es hat keine Auswirkung, wenn der Prozess existiert, löst jedoch einen Fehler aus, wenn der Prozess nicht existiert.

Windows unterstützt keine Signale, hat also kein Äquivalent zur Beendigung durch ein Signal, aber Node.js bietet eine Emulation mit process.kill() und subprocess.kill():

Das Senden von SIGINT, SIGTERM und SIGKILL führt zur bedingungslosen Beendigung des Zielprozesses, und anschließend meldet der Unterprozess, dass der Prozess durch ein Signal beendet wurde.
Das Senden des Signals 0 kann als plattformunabhängige Möglichkeit verwendet werden, um die Existenz eines Prozesses zu testen.

`process.abort()`

Hinzugefügt in: v0.7.0

Die Methode process.abort() bewirkt, dass der Node.js-Prozess sofort beendet wird und eine Core-Datei generiert wird.

Diese Funktion ist in Worker-Threads nicht verfügbar.

`process.allowedNodeEnvironmentFlags`

Hinzugefügt in: v10.10.0

<Set>

Die Eigenschaft process.allowedNodeEnvironmentFlags ist ein spezielles, schreibgeschütztes Set von Flags, die innerhalb der Umgebungsvariable NODE_OPTIONS zulässig sind.

process.allowedNodeEnvironmentFlags erweitert Set, überschreibt aber Set.prototype.has, um mehrere verschiedene mögliche Flag-Darstellungen zu erkennen. process.allowedNodeEnvironmentFlags.has() gibt in den folgenden Fällen true zurück:

Flags können führende einfache (-) oder doppelte (--) Bindestriche weglassen; z. B. inspect-brk für --inspect-brk oder r für -r.
Flags, die an V8 weitergegeben werden (wie in --v8-options aufgeführt), können einen oder mehrere nicht führende Bindestriche durch einen Unterstrich ersetzen oder umgekehrt; z. B. --perf_basic_prof, --perf-basic-prof, --perf_basic-prof usw.
Flags können ein oder mehrere Gleichheitszeichen (=) enthalten; alle Zeichen nach und einschließlich des ersten Gleichheitszeichens werden ignoriert; z. B. --stack-trace-limit=100.
Flags müssen innerhalb von NODE_OPTIONS zulässig sein.

Wenn process.allowedNodeEnvironmentFlags iteriert wird, werden Flags nur einmal angezeigt; jedes beginnt mit einem oder mehreren Bindestrichen. Flags, die an V8 weitergegeben werden, enthalten Unterstriche anstelle von nicht führenden Bindestrichen:

ESMCJS

import { allowedNodeEnvironmentFlags } from 'node:process'

allowedNodeEnvironmentFlags.forEach(flag => {
  // -r
  // --inspect-brk
  // --abort_on_uncaught_exception
  // ...
})

const { allowedNodeEnvironmentFlags } = require('node:process')

allowedNodeEnvironmentFlags.forEach(flag => {
  // -r
  // --inspect-brk
  // --abort_on_uncaught_exception
  // ...
})

Die Methoden add(), clear() und delete() von process.allowedNodeEnvironmentFlags tun nichts und schlagen stillschweigend fehl.

Wenn Node.js ohne NODE_OPTIONS-Unterstützung kompiliert wurde (gezeigt in process.config), enthält process.allowedNodeEnvironmentFlags das, was zulässig gewesen wäre.

`process.arch`

Hinzugefügt in: v0.5.0

<string>

Die CPU-Architektur des Betriebssystems, für die die Node.js-Binärdatei kompiliert wurde. Mögliche Werte sind: 'arm', 'arm64', 'ia32', 'loong64', 'mips', 'mipsel', 'ppc', 'ppc64', 'riscv64', 's390', 's390x' und 'x64'.

ESMCJS

import { arch } from 'node:process'

console.log(`Die Prozessorarchitektur ist ${arch}`)

const { arch } = require('node:process')

console.log(`Die Prozessorarchitektur ist ${arch}`)

`process.argv`

Hinzugefügt in: v0.1.27

<string[]>

Die Eigenschaft process.argv gibt ein Array zurück, das die Befehlszeilenargumente enthält, die beim Start des Node.js-Prozesses übergeben wurden. Das erste Element ist process.execPath. Siehe process.argv0, falls der Zugriff auf den Originalwert von argv[0] erforderlich ist. Das zweite Element ist der Pfad zur ausgeführten JavaScript-Datei. Die restlichen Elemente sind alle zusätzlichen Befehlszeilenargumente.

Beispielsweise wird bei folgendem Skript für process-args.js:

ESMCJS

import { argv } from 'node:process'

// print process.argv
argv.forEach((val, index) => {
  console.log(`${index}: ${val}`)
})

const { argv } = require('node:process')

// print process.argv
argv.forEach((val, index) => {
  console.log(`${index}: ${val}`)
})

Wenn der Node.js-Prozess wie folgt gestartet wird:

bash

node process-args.js one two=three four

Würde die folgende Ausgabe erzeugt:

text

0: /usr/local/bin/node
1: /Users/mjr/work/node/process-args.js
2: one
3: two=three
4: four

`process.argv0`

Hinzugefügt in: v6.4.0

<string>

Die Eigenschaft process.argv0 speichert eine schreibgeschützte Kopie des ursprünglichen Werts von argv[0], der beim Start von Node.js übergeben wurde.

bash

$ bash -c 'exec -a customArgv0 ./node'
> process.argv[0]
'/Volumes/code/external/node/out/Release/node'
> process.argv0
'customArgv0'

`process.channel`

[Historie]

Version	Änderungen
v14.0.0	Das Objekt gibt keine nativen C++-Bindungen mehr versehentlich frei.
v7.1.0	Hinzugefügt in: v7.1.0

<Object>

Wenn der Node.js-Prozess mit einem IPC-Kanal gestartet wurde (siehe die Child-Prozess-Dokumentation), ist die process.channel-Eigenschaft eine Referenz auf den IPC-Kanal. Wenn kein IPC-Kanal existiert, ist diese Eigenschaft undefined.

`process.channel.ref()`

Hinzugefügt in: v7.1.0

Diese Methode bewirkt, dass der IPC-Kanal die Ereignisschleife des Prozesses am Laufen hält, wenn .unref() zuvor aufgerufen wurde.

In der Regel wird dies durch die Anzahl der 'disconnect'- und 'message'-Listener auf dem process-Objekt verwaltet. Diese Methode kann jedoch verwendet werden, um explizit ein bestimmtes Verhalten anzufordern.

`process.channel.unref()`

Hinzugefügt in: v7.1.0

Diese Methode bewirkt, dass der IPC-Kanal die Ereignisschleife des Prozesses nicht mehr am Laufen hält und beendet, auch wenn der Kanal noch geöffnet ist.

`process.chdir(directory)`

Hinzugefügt in: v0.1.17

directory <string>

Die Methode process.chdir() ändert das aktuelle Arbeitsverzeichnis des Node.js-Prozesses oder wirft eine Ausnahme, wenn dies fehlschlägt (z. B. wenn das angegebene directory nicht existiert).

ESMCJS

import { chdir, cwd } from 'node:process'

console.log(`Startverzeichnis: ${cwd()}`)
try {
  chdir('/tmp')
  console.log(`Neues Verzeichnis: ${cwd()}`)
} catch (err) {
  console.error(`chdir: ${err}`)
}

const { chdir, cwd } = require('node:process')

console.log(`Startverzeichnis: ${cwd()}`)
try {
  chdir('/tmp')
  console.log(`Neues Verzeichnis: ${cwd()}`)
} catch (err) {
  console.error(`chdir: ${err}`)
}

Diese Funktion ist in Worker-Threads nicht verfügbar.

`process.config`

[Verlauf]

Version	Änderungen
v19.0.0	Das `process.config`-Objekt ist jetzt eingefroren.
v16.0.0	Das Ändern von process.config ist veraltet.
v0.7.7	Hinzugefügt in: v0.7.7

<Object>

Die Eigenschaft process.config gibt ein eingefrorenes Object zurück, das die JavaScript-Darstellung der Konfigurationsoptionen enthält, die zum Kompilieren der aktuellen Node.js-Ausführungsdatei verwendet wurden. Dies entspricht der Datei config.gypi, die beim Ausführen des Skripts ./configure erstellt wurde.

Ein Beispiel für die mögliche Ausgabe sieht wie folgt aus:

{
  target_defaults:
   { cflags: [],
     default_configuration: 'Release',
     defines: [],
     include_dirs: [],
     libraries: [] },
  variables:
   {
     host_arch: 'x64',
     napi_build_version: 5,
     node_install_npm: 'true',
     node_prefix: '',
     node_shared_cares: 'false',
     node_shared_http_parser: 'false',
     node_shared_libuv: 'false',
     node_shared_zlib: 'false',
     node_use_openssl: 'true',
     node_shared_openssl: 'false',
     target_arch: 'x64',
     v8_use_snapshot: 1
   }
}

`process.connected`

Hinzugefügt in: v0.7.2

<boolean>

Wenn der Node.js-Prozess mit einem IPC-Kanal (siehe die Dokumentation zu Child Process und Cluster) erzeugt wird, gibt die Eigenschaft process.connected true zurück, solange der IPC-Kanal verbunden ist, und false, nachdem process.disconnect() aufgerufen wurde.

Sobald process.connected false ist, ist es nicht mehr möglich, Nachrichten über den IPC-Kanal mit process.send() zu senden.

`process.constrainedMemory()`

[Verlauf]

Version	Änderungen
v22.0.0, v20.13.0	Ausrichtung des Rückgabewerts an `uv_get_constrained_memory`.
v19.6.0, v18.15.0	Hinzugefügt in: v19.6.0, v18.15.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

<number>

Ermittelt die Menge des für den Prozess verfügbaren Speichers (in Byte), basierend auf den vom Betriebssystem auferlegten Einschränkungen. Wenn es keine solche Einschränkung gibt oder die Einschränkung unbekannt ist, wird 0 zurückgegeben.

Weitere Informationen finden Sie unter uv_get_constrained_memory.

`process.availableMemory()`

Hinzugefügt in: v22.0.0, v20.13.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

<number>

Ermittelt die Menge an freiem Speicher, die dem Prozess noch zur Verfügung steht (in Bytes).

Weitere Informationen finden Sie unter uv_get_available_memory.

`process.cpuUsage([previousValue])`

Hinzugefügt in: v6.1.0

previousValue <Object> Ein vorheriger Rückgabewert des Aufrufs von process.cpuUsage()
Gibt zurück: <Object>
- user <integer>
- system <integer>

Die Methode process.cpuUsage() gibt die CPU-Zeitnutzung des aktuellen Prozesses für Benutzer und System in einem Objekt mit den Eigenschaften user und system zurück, deren Werte Mikrosekundenwerte (Millionstel einer Sekunde) sind. Diese Werte messen die Zeit, die jeweils im Benutzer- und Systemcode verbracht wird, und können größer als die tatsächliche verstrichene Zeit sein, wenn mehrere CPU-Kerne für diesen Prozess arbeiten.

Das Ergebnis eines vorherigen Aufrufs von process.cpuUsage() kann als Argument an die Funktion übergeben werden, um eine Differenzmessung zu erhalten.

ESMCJS

import { cpuUsage } from 'node:process'

const startUsage = cpuUsage()
// { user: 38579, system: 6986 }

// Die CPU für 500 Millisekunden belasten
const now = Date.now()
while (Date.now() - now < 500);

console.log(cpuUsage(startUsage))
// { user: 514883, system: 11226 }

const { cpuUsage } = require('node:process')

const startUsage = cpuUsage()
// { user: 38579, system: 6986 }

// Die CPU für 500 Millisekunden belasten
const now = Date.now()
while (Date.now() - now < 500);

console.log(cpuUsage(startUsage))
// { user: 514883, system: 11226 }

`process.cwd()`

Hinzugefügt in: v0.1.8

Gibt zurück: <string>

Die Methode process.cwd() gibt das aktuelle Arbeitsverzeichnis des Node.js-Prozesses zurück.

ESMCJS

import { cwd } from 'node:process'

console.log(`Aktuelles Verzeichnis: ${cwd()}`)

const { cwd } = require('node:process')

console.log(`Aktuelles Verzeichnis: ${cwd()}`)

`process.debugPort`

Hinzugefügt in: v0.7.2

<number>

Der Port, der vom Node.js-Debugger verwendet wird, wenn er aktiviert ist.

ESMCJS

import process from 'node:process'

process.debugPort = 5858

const process = require('node:process')

process.debugPort = 5858

`process.disconnect()`

Hinzugefügt in: v0.7.2

Wenn der Node.js-Prozess mit einem IPC-Kanal erzeugt wird (siehe die Dokumentation zu Child Process und Cluster), schließt die Methode process.disconnect() den IPC-Kanal zum übergeordneten Prozess und ermöglicht es dem untergeordneten Prozess, ordnungsgemäß zu beenden, sobald keine anderen Verbindungen mehr bestehen, die ihn am Leben erhalten.

Der Effekt des Aufrufs von process.disconnect() ist derselbe wie der Aufruf von ChildProcess.disconnect() vom übergeordneten Prozess.

Wenn der Node.js-Prozess nicht mit einem IPC-Kanal erzeugt wurde, ist process.disconnect() undefined.

`process.dlopen(module, filename[, flags])`

[Verlauf]

Version	Änderungen
v9.0.0	Unterstützung für das Argument `flags` hinzugefügt.
v0.1.16	Hinzugefügt in: v0.1.16

module <Object>
filename <string>
flags <os.constants.dlopen> Standard: os.constants.dlopen.RTLD_LAZY

Die Methode process.dlopen() ermöglicht das dynamische Laden von gemeinsam genutzten Objekten. Sie wird hauptsächlich von require() zum Laden von C++-Addons verwendet und sollte außer in Sonderfällen nicht direkt verwendet werden. Mit anderen Worten, require() sollte process.dlopen() vorgezogen werden, es sei denn, es gibt bestimmte Gründe, wie z. B. benutzerdefinierte dlopen-Flags oder das Laden aus ES-Modulen.

Das Argument flags ist eine Ganzzahl, mit der das dlopen-Verhalten festgelegt werden kann. Weitere Informationen finden Sie in der Dokumentation zu os.constants.dlopen.

Eine wichtige Anforderung beim Aufruf von process.dlopen() ist, dass die module-Instanz übergeben werden muss. Auf Funktionen, die vom C++-Addon exportiert werden, kann dann über module.exports zugegriffen werden.

Das folgende Beispiel zeigt, wie ein C++-Addon namens local.node geladen wird, das eine Funktion foo exportiert. Alle Symbole werden geladen, bevor der Aufruf zurückkehrt, indem die Konstante RTLD_NOW übergeben wird. In diesem Beispiel wird davon ausgegangen, dass die Konstante verfügbar ist.

ESMCJS

import { dlopen } from 'node:process'
import { constants } from 'node:os'
import { fileURLToPath } from 'node:url'

const module = { exports: {} }
dlopen(module, fileURLToPath(new URL('local.node', import.meta.url)), constants.dlopen.RTLD_NOW)
module.exports.foo()

const { dlopen } = require('node:process')
const { constants } = require('node:os')
const { join } = require('node:path')

const module = { exports: {} }
dlopen(module, join(__dirname, 'local.node'), constants.dlopen.RTLD_NOW)
module.exports.foo()

`process.emitWarning(warning[, options])`

Hinzugefügt in: v8.0.0

warning <string> | <Error> Die auszugebende Warnung.
options <Object>
- type <string> Wenn warning ein String ist, ist type der Name, der für den Typ der ausgegebenen Warnung verwendet wird. Standard: 'Warning'.
- code <string> Ein eindeutiger Bezeichner für die ausgegebene Warnungsinstanz.
- ctor <Function> Wenn warning ein String ist, ist ctor eine optionale Funktion, die verwendet wird, um den generierten Stack-Trace einzuschränken. Standard: process.emitWarning.
- detail <string> Zusätzlicher Text, der mit dem Fehler enthalten sein soll.

Die Methode process.emitWarning() kann verwendet werden, um benutzerdefinierte oder anwendungsspezifische Prozesswarnungen auszugeben. Diese können abgefangen werden, indem ein Handler zum 'warning'-Event hinzugefügt wird.

ESMCJS

import { emitWarning } from 'node:process'

// Gibt eine Warnung mit einem Code und zusätzlichen Details aus.
emitWarning('Etwas ist passiert!', {
  code: 'MEINE_WARNUNG',
  detail: 'Dies sind einige zusätzliche Informationen',
})
// Gibt aus:
// (node:56338) [MEINE_WARNUNG] Warning: Etwas ist passiert!
// Dies sind einige zusätzliche Informationen

const { emitWarning } = require('node:process')

// Gibt eine Warnung mit einem Code und zusätzlichen Details aus.
emitWarning('Etwas ist passiert!', {
  code: 'MEINE_WARNUNG',
  detail: 'Dies sind einige zusätzliche Informationen',
})
// Gibt aus:
// (node:56338) [MEINE_WARNUNG] Warning: Etwas ist passiert!
// Dies sind einige zusätzliche Informationen

In diesem Beispiel wird intern ein Error-Objekt von process.emitWarning() generiert und an den 'warning'-Handler übergeben.

ESMCJS

import process from 'node:process'

process.on('warning', warning => {
  console.warn(warning.name) // 'Warning'
  console.warn(warning.message) // 'Etwas ist passiert!'
  console.warn(warning.code) // 'MEINE_WARNUNG'
  console.warn(warning.stack) // Stack-Trace
  console.warn(warning.detail) // 'Dies sind einige zusätzliche Informationen'
})

const process = require('node:process')

process.on('warning', warning => {
  console.warn(warning.name) // 'Warning'
  console.warn(warning.message) // 'Etwas ist passiert!'
  console.warn(warning.code) // 'MEINE_WARNUNG'
  console.warn(warning.stack) // Stack-Trace
  console.warn(warning.detail) // 'Dies sind einige zusätzliche Informationen'
})

Wenn warning als Error-Objekt übergeben wird, wird das options-Argument ignoriert.

`process.emitWarning(warning[, type[, code]][, ctor])`

Hinzugefügt in: v6.0.0

warning <string> | <Error> Die Warnung, die ausgegeben werden soll.
type <string> Wenn warning ein String ist, ist type der Name, der für den Typ der ausgegebenen Warnung verwendet wird. Standard: 'Warning'.
code <string> Eine eindeutige Kennung für die ausgegebene Warnungsinstanz.
ctor <Function> Wenn warning ein String ist, ist ctor eine optionale Funktion, die verwendet wird, um den generierten Stack Trace zu begrenzen. Standard: process.emitWarning.

Die process.emitWarning()-Methode kann verwendet werden, um benutzerdefinierte oder anwendungsspezifische Prozesswarnungen auszugeben. Diese können abgehört werden, indem ein Handler zum 'warning'-Ereignis hinzugefügt wird.

ESMCJS

import { emitWarning } from 'node:process'

// Gibt eine Warnung mithilfe einer Zeichenkette aus.
emitWarning('Etwas ist passiert!')
// Gibt aus: (node: 56338) Warnung: Etwas ist passiert!

const { emitWarning } = require('node:process')

// Gibt eine Warnung mithilfe einer Zeichenkette aus.
emitWarning('Etwas ist passiert!')
// Gibt aus: (node: 56338) Warnung: Etwas ist passiert!

ESMCJS

import { emitWarning } from 'node:process'

// Gibt eine Warnung mithilfe einer Zeichenkette und einem Typ aus.
emitWarning('Etwas ist passiert!', 'CustomWarning')
// Gibt aus: (node:56338) CustomWarning: Etwas ist passiert!

const { emitWarning } = require('node:process')

// Gibt eine Warnung mithilfe einer Zeichenkette und einem Typ aus.
emitWarning('Etwas ist passiert!', 'CustomWarning')
// Gibt aus: (node:56338) CustomWarning: Etwas ist passiert!

ESMCJS

import { emitWarning } from 'node:process'

emitWarning('Etwas ist passiert!', 'CustomWarning', 'WARN001')
// Gibt aus: (node:56338) [WARN001] CustomWarning: Etwas ist passiert!

const { emitWarning } = require('node:process')

process.emitWarning('Etwas ist passiert!', 'CustomWarning', 'WARN001')
// Gibt aus: (node:56338) [WARN001] CustomWarning: Etwas ist passiert!

In jedem der vorherigen Beispiele wird intern ein Error-Objekt von process.emitWarning() generiert und an den 'warning'-Handler übergeben.

ESMCJS

import process from 'node:process'

process.on('warning', warning => {
  console.warn(warning.name)
  console.warn(warning.message)
  console.warn(warning.code)
  console.warn(warning.stack)
})

const process = require('node:process')

process.on('warning', warning => {
  console.warn(warning.name)
  console.warn(warning.message)
  console.warn(warning.code)
  console.warn(warning.stack)
})

Wenn warning als Error-Objekt übergeben wird, wird es unverändert an den 'warning'-Ereignis-Handler weitergegeben (und die optionalen Argumente type, code und ctor werden ignoriert):

ESMCJS

import { emitWarning } from 'node:process'

// Gibt eine Warnung mithilfe eines Error-Objekts aus.
const myWarning = new Error('Etwas ist passiert!')
// Verwenden Sie die Name-Eigenschaft des Fehlers, um den Typnamen anzugeben
myWarning.name = 'CustomWarning'
myWarning.code = 'WARN001'

emitWarning(myWarning)
// Gibt aus: (node:56338) [WARN001] CustomWarning: Etwas ist passiert!

const { emitWarning } = require('node:process')

// Gibt eine Warnung mithilfe eines Error-Objekts aus.
const myWarning = new Error('Etwas ist passiert!')
// Verwenden Sie die Name-Eigenschaft des Fehlers, um den Typnamen anzugeben
myWarning.name = 'CustomWarning'
myWarning.code = 'WARN001'

emitWarning(myWarning)
// Gibt aus: (node:56338) [WARN001] CustomWarning: Etwas ist passiert!

Ein TypeError wird ausgelöst, wenn warning etwas anderes als ein String oder ein Error-Objekt ist.

Obwohl Prozesswarnungen Error-Objekte verwenden, ist der Prozesswarnmechanismus kein Ersatz für normale Fehlerbehandlungsmechanismen.

Die folgende zusätzliche Behandlung wird implementiert, wenn der Warnungstyp 'DeprecationWarning' ist:

Wenn das Befehlszeilenflag --throw-deprecation verwendet wird, wird die Deprecation-Warnung als Ausnahme ausgelöst, anstatt als Ereignis ausgegeben zu werden.
Wenn das Befehlszeilenflag --no-deprecation verwendet wird, wird die Deprecation-Warnung unterdrückt.
Wenn das Befehlszeilenflag --trace-deprecation verwendet wird, wird die Deprecation-Warnung zusammen mit dem vollständigen Stack Trace auf stderr ausgegeben.

Doppelte Warnungen vermeiden

Als bewährte Methode sollten Warnungen nur einmal pro Prozess ausgegeben werden. Um dies zu erreichen, platzieren Sie emitWarning() hinter einem Booleschen Wert.

ESMCJS

import { emitWarning } from 'node:process'

function emitMyWarning() {
  if (!emitMyWarning.warned) {
    emitMyWarning.warned = true
    emitWarning('Nur einmal warnen!')
  }
}
emitMyWarning()
// Gibt aus: (node: 56339) Warning: Nur einmal warnen!
emitMyWarning()
// Gibt nichts aus

const { emitWarning } = require('node:process')

function emitMyWarning() {
  if (!emitMyWarning.warned) {
    emitMyWarning.warned = true
    emitWarning('Nur einmal warnen!')
  }
}
emitMyWarning()
// Gibt aus: (node: 56339) Warning: Nur einmal warnen!
emitMyWarning()
// Gibt nichts aus

`process.env`

[Historie]

Version	Änderungen
v11.14.0	Worker-Threads verwenden standardmäßig eine Kopie von `process.env` des übergeordneten Threads, die über die `env`-Option des `Worker`-Konstruktors konfiguriert werden kann.
v10.0.0	Die implizite Konvertierung des Variablenwerts in einen String ist veraltet.
v0.1.27	Hinzugefügt in: v0.1.27

<Object>

Die process.env-Eigenschaft gibt ein Objekt mit der Benutzerumgebung zurück. Siehe environ(7).

Ein Beispiel für dieses Objekt sieht so aus:

{
  TERM: 'xterm-256color',
  SHELL: '/usr/local/bin/bash',
  USER: 'maciej',
  PATH: '~/.bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin',
  PWD: '/Users/maciej',
  EDITOR: 'vim',
  SHLVL: '1',
  HOME: '/Users/maciej',
  LOGNAME: 'maciej',
  _: '/usr/local/bin/node'
}

Es ist möglich, dieses Objekt zu ändern, aber solche Änderungen werden nicht außerhalb des Node.js-Prozesses oder (sofern nicht ausdrücklich gewünscht) an andere Worker-Threads weitergegeben. Mit anderen Worten, das folgende Beispiel würde nicht funktionieren:

bash

node -e 'process.env.foo = "bar"' && echo $foo

Während das Folgende funktionieren wird:

ESMCJS

import { env } from 'node:process'

env.foo = 'bar'
console.log(env.foo)

const { env } = require('node:process')

env.foo = 'bar'
console.log(env.foo)

Das Zuweisen einer Eigenschaft zu process.env konvertiert den Wert implizit in einen String. Dieses Verhalten ist veraltet. Zukünftige Versionen von Node.js können einen Fehler auslösen, wenn der Wert kein String, keine Zahl oder kein boolescher Wert ist.

ESMCJS

import { env } from 'node:process'

env.test = null
console.log(env.test)
// => 'null'
env.test = undefined
console.log(env.test)
// => 'undefined'

const { env } = require('node:process')

env.test = null
console.log(env.test)
// => 'null'
env.test = undefined
console.log(env.test)
// => 'undefined'

Verwenden Sie delete, um eine Eigenschaft aus process.env zu löschen.

ESMCJS

import { env } from 'node:process'

env.TEST = 1
delete env.TEST
console.log(env.TEST)
// => undefined

const { env } = require('node:process')

env.TEST = 1
delete env.TEST
console.log(env.TEST)
// => undefined

Unter Windows-Betriebssystemen wird bei Umgebungsvariablen nicht zwischen Groß- und Kleinschreibung unterschieden.

ESMCJS

import { env } from 'node:process'

env.TEST = 1
console.log(env.test)
// => 1

const { env } = require('node:process')

env.TEST = 1
console.log(env.test)
// => 1

Sofern nicht ausdrücklich beim Erstellen einer Worker-Instanz angegeben, hat jeder Worker-Thread seine eigene Kopie von process.env, die auf dem process.env des übergeordneten Threads basiert oder auf dem, was als env-Option für den Worker-Konstruktor angegeben wurde. Änderungen an process.env sind nicht über Worker-Threads hinweg sichtbar, und nur der Hauptthread kann Änderungen vornehmen, die für das Betriebssystem oder für native Add-ons sichtbar sind. Unter Windows arbeitet eine Kopie von process.env auf einer Worker-Instanz im Gegensatz zum Hauptthread in einer Weise, bei der zwischen Groß- und Kleinschreibung unterschieden wird.

`process.execArgv`

Hinzugefügt in: v0.7.7

<string[]>

Die Eigenschaft process.execArgv gibt die Menge der Node.js-spezifischen Befehlszeilenoptionen zurück, die beim Start des Node.js-Prozesses übergeben wurden. Diese Optionen erscheinen nicht im Array, das von der Eigenschaft process.argv zurückgegeben wird, und enthalten weder die ausführbare Node.js-Datei noch den Namen des Skripts oder irgendwelche Optionen nach dem Skriptnamen. Diese Optionen sind nützlich, um Kindprozesse mit der gleichen Ausführungsumgebung wie der Elternprozess zu erzeugen.

bash

node --icu-data-dir=./foo --require ./bar.js script.js --version

Ergibt in process.execArgv:

json

["--icu-data-dir=./foo", "--require", "./bar.js"]

Und process.argv:

;['/usr/local/bin/node', 'script.js', '--version']

Weitere Informationen zum detaillierten Verhalten von Worker-Threads mit dieser Eigenschaft finden Sie unter Worker-Konstruktor.

`process.execPath`

Hinzugefügt in: v0.1.100

<string>

Die Eigenschaft process.execPath gibt den absoluten Pfadnamen der ausführbaren Datei zurück, die den Node.js-Prozess gestartet hat. Symbolische Links, falls vorhanden, werden aufgelöst.

'/usr/local/bin/node'

`process.exit([code])`

[Verlauf]

Version	Änderungen
v20.0.0	Akzeptiert nur einen Code vom Typ Zahl oder vom Typ String, wenn er eine ganze Zahl darstellt.
v0.1.13	Hinzugefügt in: v0.1.13

code <integer> | <string> | <null> | <undefined> Der Exit-Code. Für den String-Typ sind nur ganzzahlige Strings (z. B. '1') zulässig. Standard: 0.

Die Methode process.exit() weist Node.js an, den Prozess synchron mit dem Exit-Status code zu beenden. Wenn code weggelassen wird, verwendet exit entweder den 'Erfolgs'-Code 0 oder den Wert von process.exitCode, falls dieser gesetzt wurde. Node.js wird nicht beendet, bis alle ['exit']-Ereignislistener aufgerufen wurden.

So beenden Sie mit einem 'Fehler'-Code:

ESMCJS

import { exit } from 'node:process'

exit(1)

const { exit } = require('node:process')

exit(1)

Die Shell, die Node.js ausgeführt hat, sollte den Exit-Code als 1 sehen.

Der Aufruf von process.exit() zwingt den Prozess, so schnell wie möglich zu beenden, auch wenn noch asynchrone Operationen ausstehen, die noch nicht vollständig abgeschlossen wurden, einschließlich E/A-Operationen auf process.stdout und process.stderr.

In den meisten Situationen ist es nicht wirklich notwendig, process.exit() explizit aufzurufen. Der Node.js-Prozess wird sich von selbst beenden, wenn keine zusätzliche Arbeit in der Ereignisschleife aussteht. Die Eigenschaft process.exitCode kann gesetzt werden, um dem Prozess mitzuteilen, welchen Exit-Code er verwenden soll, wenn der Prozess ordnungsgemäß beendet wird.

Das folgende Beispiel veranschaulicht beispielsweise einen Missbrauch der Methode process.exit(), der dazu führen könnte, dass auf stdout gedruckte Daten abgeschnitten werden und verloren gehen:

ESMCJS

import { exit } from 'node:process'

// Dies ist ein Beispiel dafür, was *nicht* zu tun ist:
if (someConditionNotMet()) {
  printUsageToStdout()
  exit(1)
}

const { exit } = require('node:process')

// Dies ist ein Beispiel dafür, was *nicht* zu tun ist:
if (someConditionNotMet()) {
  printUsageToStdout()
  exit(1)
}

Das Problem dabei ist, dass Schreibvorgänge in process.stdout in Node.js manchmal asynchron sind und über mehrere Ticks der Node.js-Ereignisschleife erfolgen können. Der Aufruf von process.exit() zwingt den Prozess jedoch, bevor diese zusätzlichen Schreibvorgänge auf stdout durchgeführt werden können, zu beenden.

Anstatt process.exit() direkt aufzurufen, sollte der Code die process.exitCode setzen und dem Prozess ermöglichen, auf natürliche Weise zu beenden, indem er die Planung zusätzlicher Arbeit für die Ereignisschleife vermeidet:

ESMCJS

import process from 'node:process'

// So setzen Sie den Exit-Code richtig, während
// der Prozess ordnungsgemäß beendet wird.
if (someConditionNotMet()) {
  printUsageToStdout()
  process.exitCode = 1
}

const process = require('node:process')

// So setzen Sie den Exit-Code richtig, während
// der Prozess ordnungsgemäß beendet wird.
if (someConditionNotMet()) {
  printUsageToStdout()
  process.exitCode = 1
}

Wenn es notwendig ist, den Node.js-Prozess aufgrund eines Fehlerzustands zu beenden, ist das Auslösen eines nicht abgefangenen Fehlers und das Zulassen, dass der Prozess entsprechend beendet wird, sicherer als der Aufruf von process.exit().

In Worker-Threads beendet diese Funktion den aktuellen Thread und nicht den aktuellen Prozess.

`process.exitCode`

[Verlauf]

Version	Änderungen
v20.0.0	Akzeptiert nur einen Code vom Typ Zahl oder vom Typ String, wenn er eine ganze Zahl darstellt.
v0.11.8	Hinzugefügt in: v0.11.8

<integer> | <string> | <null> | <undefined> Der Exit-Code. Für den String-Typ sind nur Integer-Strings (z. B. '1') zulässig. Standard: undefined.

Eine Zahl, die der Exit-Code des Prozesses ist, wenn der Prozess entweder ordnungsgemäß beendet wird oder über process.exit() ohne Angabe eines Codes beendet wird.

Die Angabe eines Codes für process.exit(code) überschreibt jede vorherige Einstellung von process.exitCode.

`process.features.cached_builtins`

Hinzugefügt in: v12.0.0

<boolean>

Ein boolescher Wert, der true ist, wenn der aktuelle Node.js-Build integrierte Module zwischenspeichert.

`process.features.debug`

Hinzugefügt in: v0.5.5

<boolean>

Ein boolescher Wert, der true ist, wenn der aktuelle Node.js-Build ein Debug-Build ist.

`process.features.inspector`

Hinzugefügt in: v11.10.0

<boolean>

Ein boolescher Wert, der true ist, wenn der aktuelle Node.js-Build den Inspector enthält.

`process.features.ipv6`

Hinzugefügt in: v0.5.3

Veraltet seit: v23.4.0

[Stabil: 0 - Veraltet]

Stabil: 0 Stabilität: 0 - Veraltet. Diese Eigenschaft ist immer true, und alle darauf basierenden Prüfungen sind redundant.

<boolean>

Ein boolescher Wert, der true ist, wenn der aktuelle Node.js-Build Unterstützung für IPv6 enthält.

Da alle Node.js-Builds IPv6-Unterstützung haben, ist dieser Wert immer true.

`process.features.require_module`

Hinzugefügt in: v23.0.0

<boolean>

Ein boolescher Wert, der true ist, wenn der aktuelle Node.js-Build das Laden von ECMAScript-Modulen mit require() unterstützt.

`process.features.tls`

Hinzugefügt in: v0.5.3

<boolean>

Ein boolescher Wert, der true ist, wenn der aktuelle Node.js-Build Unterstützung für TLS enthält.

`process.features.tls_alpn`

Hinzugefügt in: v4.8.0

Veraltet seit: v23.4.0

[Stabil: 0 - Veraltet]

Stabil: 0 Stabilität: 0 - Veraltet. Verwenden Sie stattdessen process.features.tls.

<boolean>

Ein boolescher Wert, der true ist, wenn der aktuelle Node.js-Build Unterstützung für ALPN in TLS enthält.

In Node.js 11.0.0 und späteren Versionen bieten die OpenSSL-Abhängigkeiten bedingungslose ALPN-Unterstützung. Dieser Wert ist daher identisch mit dem von process.features.tls.

`process.features.tls_ocsp`

Hinzugefügt in: v0.11.13

Veraltet seit: v23.4.0

[Stabil: 0 - Veraltet]

Stabil: 0 Stabilität: 0 - Veraltet. Verwenden Sie stattdessen process.features.tls.

<boolean>

Ein boolescher Wert, der true ist, wenn der aktuelle Node.js-Build Unterstützung für OCSP in TLS enthält.

In Node.js 11.0.0 und späteren Versionen bieten die OpenSSL-Abhängigkeiten bedingungslose OCSP-Unterstützung. Dieser Wert ist daher identisch mit dem von process.features.tls.

`process.features.tls_sni`

Hinzugefügt in: v0.5.3

Veraltet seit: v23.4.0

[Stabil: 0 - Veraltet]

Stabil: 0 Stabilität: 0 - Veraltet. Verwenden Sie stattdessen process.features.tls.

<boolean>

Ein boolescher Wert, der true ist, wenn der aktuelle Node.js-Build Unterstützung für SNI in TLS enthält.

In Node.js 11.0.0 und späteren Versionen bieten die OpenSSL-Abhängigkeiten bedingungslose SNI-Unterstützung. Dieser Wert ist daher identisch mit dem von process.features.tls.

`process.features.typescript`

Hinzugefügt in: v23.0.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.1 - Aktive Entwicklung

<boolean> | <string>

Ein Wert, der "strip" ist, wenn Node.js mit --experimental-strip-types ausgeführt wird, "transform", wenn Node.js mit --experimental-transform-types ausgeführt wird, und ansonsten false.

`process.features.uv`

Hinzugefügt in: v0.5.3

Veraltet seit: v23.4.0

[Stabil: 0 - Veraltet]

Stabil: 0 Stabilität: 0 - Veraltet. Diese Eigenschaft ist immer wahr und alle darauf basierenden Prüfungen sind redundant.

<boolean>

Ein boolescher Wert, der true ist, wenn der aktuelle Node.js-Build Unterstützung für libuv enthält.

Da es nicht möglich ist, Node.js ohne libuv zu erstellen, ist dieser Wert immer true.

`process.finalization.register(ref, callback)`

Hinzugefügt in: v22.5.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.1 - Aktive Entwicklung

ref <Object> | <Function> Die Referenz auf die Ressource, die verfolgt wird.
callback <Function> Die Callback-Funktion, die aufgerufen werden soll, wenn die Ressource freigegeben wird.
- ref <Object> | <Function> Die Referenz auf die Ressource, die verfolgt wird.
- event <string> Das Ereignis, das die Freigabe ausgelöst hat. Standardmäßig 'exit'.

Diese Funktion registriert einen Callback, der aufgerufen wird, wenn der Prozess das exit-Ereignis auslöst, falls das ref-Objekt nicht von der Garbage Collection entfernt wurde. Wenn das Objekt ref vor dem Auslösen des exit-Ereignisses von der Garbage Collection entfernt wurde, wird der Callback aus der Finalisierungsregistrierung entfernt und wird beim Beenden des Prozesses nicht aufgerufen.

Innerhalb des Callbacks können Sie die vom ref-Objekt zugewiesenen Ressourcen freigeben. Beachten Sie, dass alle Einschränkungen, die für das beforeExit-Ereignis gelten, auch für die Callback-Funktion gelten. Dies bedeutet, dass die Möglichkeit besteht, dass der Callback unter besonderen Umständen nicht aufgerufen wird.

Die Idee dieser Funktion ist es, Ihnen zu helfen, Ressourcen freizugeben, wenn der Prozess mit dem Beenden beginnt, aber das Objekt auch von der Garbage Collection entfernen zu lassen, wenn es nicht mehr verwendet wird.

Beispiel: Sie können ein Objekt registrieren, das einen Puffer enthält. Sie möchten sicherstellen, dass der Puffer freigegeben wird, wenn der Prozess beendet wird. Wenn das Objekt jedoch vor dem Beenden des Prozesses von der Garbage Collection entfernt wird, müssen wir den Puffer nicht mehr freigeben. In diesem Fall entfernen wir einfach den Callback aus der Finalisierungsregistrierung.

CJSESM

const { finalization } = require('node:process')

// Bitte stellen Sie sicher, dass die Funktion, die an finalization.register() übergeben wird,
// keine Closure um unnötige Objekte herum erstellt.
function onFinalize(obj, event) {
  // Sie können mit dem Objekt tun, was Sie wollen
  obj.dispose()
}

function setup() {
  // Dieses Objekt kann sicher von der Garbage Collection entfernt werden,
  // und die resultierende Shutdown-Funktion wird nicht aufgerufen.
  // Es gibt keine Lecks.
  const myDisposableObject = {
    dispose() {
      // Geben Sie Ihre Ressourcen synchron frei
    },
  }

  finalization.register(myDisposableObject, onFinalize)
}

setup()

import { finalization } from 'node:process'

// Bitte stellen Sie sicher, dass die Funktion, die an finalization.register() übergeben wird,
// keine Closure um unnötige Objekte herum erstellt.
function onFinalize(obj, event) {
  // Sie können mit dem Objekt tun, was Sie wollen
  obj.dispose()
}

function setup() {
  // Dieses Objekt kann sicher von der Garbage Collection entfernt werden,
  // und die resultierende Shutdown-Funktion wird nicht aufgerufen.
  // Es gibt keine Lecks.
  const myDisposableObject = {
    dispose() {
      // Geben Sie Ihre Ressourcen synchron frei
    },
  }

  finalization.register(myDisposableObject, onFinalize)
}

setup()

Der obige Code basiert auf folgenden Annahmen:

Pfeilfunktionen werden vermieden
reguläre Funktionen werden empfohlen, sich im globalen Kontext (root) zu befinden

Reguläre Funktionen könnten auf den Kontext verweisen, in dem das obj lebt, wodurch das obj nicht von der Garbage Collection entfernt werden kann.

Pfeilfunktionen behalten den vorherigen Kontext bei. Betrachten Sie beispielsweise:

class Test {
  constructor() {
    finalization.register(this, ref => ref.dispose())

    // Selbst so etwas ist sehr unerwünscht
    // finalization.register(this, () => this.dispose());
  }
  dispose() {}
}

Es ist sehr unwahrscheinlich (nicht unmöglich), dass dieses Objekt von der Garbage Collection entfernt wird, aber wenn dies nicht der Fall ist, wird dispose aufgerufen, wenn process.exit aufgerufen wird.

Seien Sie vorsichtig und verlassen Sie sich nicht auf diese Funktion für die Freigabe kritischer Ressourcen, da nicht garantiert ist, dass der Callback unter allen Umständen aufgerufen wird.

`process.finalization.registerBeforeExit(ref, callback)`

Hinzugefügt in: v22.5.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.1 - Aktive Entwicklung

ref <Object> | <Function> Der Verweis auf die Ressource, die verfolgt wird.
callback <Function> Die Callback-Funktion, die aufgerufen wird, wenn die Ressource finalisiert wird.
- ref <Object> | <Function> Der Verweis auf die Ressource, die verfolgt wird.
- event <string> Das Ereignis, das die Finalisierung ausgelöst hat. Standardmäßig 'beforeExit'.

Diese Funktion verhält sich genau wie register, mit der Ausnahme, dass der Callback aufgerufen wird, wenn der Prozess das beforeExit-Ereignis ausgibt, falls das ref-Objekt nicht per Garbage Collection entfernt wurde.

Beachten Sie, dass alle Einschränkungen, die für das beforeExit-Ereignis gelten, auch für die callback-Funktion gelten. Das bedeutet, dass es unter besonderen Umständen möglich ist, dass der Callback nicht aufgerufen wird.

`process.finalization.unregister(ref)`

Hinzugefügt in: v22.5.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.1 - Aktive Entwicklung

ref <Object> | <Function> Der Verweis auf die Ressource, die zuvor registriert wurde.

Diese Funktion entfernt die Registrierung des Objekts aus der Finalisierungsregistrierung, so dass der Callback nicht mehr aufgerufen wird.

CJSESM

const { finalization } = require('node:process')

// Bitte stellen Sie sicher, dass die an finalization.register() übergebene Funktion
// keinen Closure um unnötige Objekte erzeugt.
function onFinalize(obj, event) {
  // Sie können mit dem Objekt tun, was Sie möchten
  obj.dispose()
}

function setup() {
  // Dieses Objekt kann sicher per Garbage Collection entfernt werden,
  // und die resultierende Shutdown-Funktion wird nicht aufgerufen.
  // Es gibt keine Lecks.
  const myDisposableObject = {
    dispose() {
      // Geben Sie Ihre Ressourcen synchron frei
    },
  }

  finalization.register(myDisposableObject, onFinalize)

  // Tun Sie etwas

  myDisposableObject.dispose()
  finalization.unregister(myDisposableObject)
}

setup()

import { finalization } from 'node:process'

// Bitte stellen Sie sicher, dass die an finalization.register() übergebene Funktion
// keinen Closure um unnötige Objekte erzeugt.
function onFinalize(obj, event) {
  // Sie können mit dem Objekt tun, was Sie möchten
  obj.dispose()
}

function setup() {
  // Dieses Objekt kann sicher per Garbage Collection entfernt werden,
  // und die resultierende Shutdown-Funktion wird nicht aufgerufen.
  // Es gibt keine Lecks.
  const myDisposableObject = {
    dispose() {
      // Geben Sie Ihre Ressourcen synchron frei
    },
  }

  // Bitte stellen Sie sicher, dass die an finalization.register() übergebene Funktion
  // keinen Closure um unnötige Objekte erzeugt.
  function onFinalize(obj, event) {
    // Sie können mit dem Objekt tun, was Sie möchten
    obj.dispose()
  }

  finalization.register(myDisposableObject, onFinalize)

  // Tun Sie etwas

  myDisposableObject.dispose()
  finalization.unregister(myDisposableObject)
}

setup()

`process.getActiveResourcesInfo()`

Hinzugefügt in: v17.3.0, v16.14.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

Gibt zurück: <string[]>

Die Methode process.getActiveResourcesInfo() gibt ein Array von Strings zurück, die die Typen der aktiven Ressourcen enthalten, die die Ereignisschleife aktuell am Laufen halten.

ESMCJS

import { getActiveResourcesInfo } from 'node:process'
import { setTimeout } from 'node:timers'

console.log('Vorher:', getActiveResourcesInfo())
setTimeout(() => {}, 1000)
console.log('Nachher:', getActiveResourcesInfo())
// Gibt aus:
//   Vorher: [ 'CloseReq', 'TTYWrap', 'TTYWrap', 'TTYWrap' ]
//   Nachher: [ 'CloseReq', 'TTYWrap', 'TTYWrap', 'TTYWrap', 'Timeout' ]

const { getActiveResourcesInfo } = require('node:process')
const { setTimeout } = require('node:timers')

console.log('Vorher:', getActiveResourcesInfo())
setTimeout(() => {}, 1000)
console.log('Nachher:', getActiveResourcesInfo())
// Gibt aus:
//   Vorher: [ 'TTYWrap', 'TTYWrap', 'TTYWrap' ]
//   Nachher: [ 'TTYWrap', 'TTYWrap', 'TTYWrap', 'Timeout' ]

`process.getBuiltinModule(id)`

Hinzugefügt in: v22.3.0, v20.16.0

id <string> ID des angeforderten eingebauten Moduls.
Gibt zurück: <Object> | <undefined>

process.getBuiltinModule(id) bietet eine Möglichkeit, eingebaute Module in einer global verfügbaren Funktion zu laden. ES-Module, die andere Umgebungen unterstützen müssen, können es verwenden, um ein in Node.js eingebautes Modul bedingt zu laden, wenn es in Node.js ausgeführt wird, ohne sich mit dem Auflösungsfehler auseinandersetzen zu müssen, der von import in einer Nicht-Node.js-Umgebung ausgelöst werden kann, oder dynamisches import() verwenden zu müssen, was entweder das Modul in ein asynchrones Modul verwandelt oder eine synchrone API in eine asynchrone verwandelt.

if (globalThis.process?.getBuiltinModule) {
  // Ausführung in Node.js, Verwendung des Node.js-fs-Moduls.
  const fs = globalThis.process.getBuiltinModule('fs')
  // Wenn `require()` zum Laden von Benutzermodulen benötigt wird, verwende createRequire()
  const module = globalThis.process.getBuiltinModule('module')
  const require = module.createRequire(import.meta.url)
  const foo = require('foo')
}

Wenn id ein eingebautes Modul angibt, das im aktuellen Node.js-Prozess verfügbar ist, gibt die Methode process.getBuiltinModule(id) das entsprechende eingebaute Modul zurück. Wenn id keinem eingebauten Modul entspricht, wird undefined zurückgegeben.

process.getBuiltinModule(id) akzeptiert IDs eingebauter Module, die von module.isBuiltin(id) erkannt werden. Einige eingebaute Module müssen mit dem Präfix node: geladen werden, siehe eingebaute Module mit obligatorischem node: Präfix. Die von process.getBuiltinModule(id) zurückgegebenen Referenzen zeigen immer auf das eingebaute Modul, das id entspricht, selbst wenn Benutzer require.cache so ändern, dass require(id) etwas anderes zurückgibt.

`process.getegid()`

Hinzugefügt in: v2.0.0

Die Methode process.getegid() gibt die numerische effektive Gruppenidentität des Node.js-Prozesses zurück. (Siehe getegid(2).)

ESMCJS

import process from 'node:process'

if (process.getegid) {
  console.log(`Aktuelle GID: ${process.getegid()}`)
}

const process = require('node:process')

if (process.getegid) {
  console.log(`Aktuelle GID: ${process.getegid()}`)
}

Diese Funktion ist nur auf POSIX-Plattformen verfügbar (d.h. nicht Windows oder Android).

`process.geteuid()`

Hinzugefügt in: v2.0.0

Gibt zurück: <Object>

Die Methode process.geteuid() gibt die numerische effektive Benutzeridentität des Prozesses zurück. (Siehe geteuid(2).)

ESMCJS

import process from 'node:process'

if (process.geteuid) {
  console.log(`Aktuelle UID: ${process.geteuid()}`)
}

const process = require('node:process')

if (process.geteuid) {
  console.log(`Aktuelle UID: ${process.geteuid()}`)
}

Diese Funktion ist nur auf POSIX-Plattformen verfügbar (d.h. nicht Windows oder Android).

`process.getgid()`

Hinzugefügt in: v0.1.31

Gibt zurück: <Object>

Die Methode process.getgid() gibt die numerische Gruppenidentität des Prozesses zurück. (Siehe getgid(2).)

ESMCJS

import process from 'node:process'

if (process.getgid) {
  console.log(`Aktuelle GID: ${process.getgid()}`)
}

const process = require('node:process')

if (process.getgid) {
  console.log(`Aktuelle GID: ${process.getgid()}`)
}

Diese Funktion ist nur auf POSIX-Plattformen verfügbar (d.h. nicht Windows oder Android).

`process.getgroups()`

Hinzugefügt in: v0.9.4

Gibt zurück: <integer[]>

Die Methode process.getgroups() gibt ein Array mit den zusätzlichen Gruppen-IDs zurück. POSIX lässt es unspezifiziert, ob die effektive Gruppen-ID enthalten ist, aber Node.js stellt sicher, dass dies immer der Fall ist.

ESMCJS

import process from 'node:process'

if (process.getgroups) {
  console.log(process.getgroups()) // [ 16, 21, 297 ]
}

const process = require('node:process')

if (process.getgroups) {
  console.log(process.getgroups()) // [ 16, 21, 297 ]
}

Diese Funktion ist nur auf POSIX-Plattformen verfügbar (d.h. nicht Windows oder Android).

`process.getuid()`

Hinzugefügt in: v0.1.28

Gibt zurück: <integer>

Die Methode process.getuid() gibt die numerische Benutzeridentität des Prozesses zurück. (Siehe getuid(2).)

ESMCJS

import process from 'node:process'

if (process.getuid) {
  console.log(`Aktuelle UID: ${process.getuid()}`)
}

const process = require('node:process')

if (process.getuid) {
  console.log(`Aktuelle UID: ${process.getuid()}`)
}

Diese Funktion ist nur auf POSIX-Plattformen verfügbar (d. h. nicht unter Windows oder Android).

`process.hasUncaughtExceptionCaptureCallback()`

Hinzugefügt in: v9.3.0

Gibt zurück: <boolean>

Gibt an, ob ein Callback mit process.setUncaughtExceptionCaptureCallback() festgelegt wurde.

`process.hrtime([time])`

Hinzugefügt in: v0.7.6

[Stabil: 3 - Legacy]

Stabil: 3 Stabilität: 3 - Legacy. Verwenden Sie stattdessen process.hrtime.bigint().

time <integer[]> Das Ergebnis eines vorherigen Aufrufs von process.hrtime()
Gibt zurück: <integer[]>

Dies ist die Legacy-Version von process.hrtime.bigint(), bevor bigint in JavaScript eingeführt wurde.

Die Methode process.hrtime() gibt die aktuelle hochauflösende Echtzeit in einem [Sekunden, Nanosekunden]-Tupel-Array zurück, wobei Nanosekunden der verbleibende Teil der Echtzeit ist, der nicht in Sekundengenauigkeit dargestellt werden kann.

time ist ein optionaler Parameter, der das Ergebnis eines vorherigen process.hrtime()-Aufrufs sein muss, um mit der aktuellen Zeit zu differenzieren. Wenn der übergebene Parameter kein Tupel-Array ist, wird ein TypeError ausgelöst. Das Übergeben eines benutzerdefinierten Arrays anstelle des Ergebnisses eines vorherigen Aufrufs von process.hrtime() führt zu undefiniertem Verhalten.

Diese Zeiten beziehen sich auf einen beliebigen Zeitpunkt in der Vergangenheit und nicht auf die Tageszeit und sind daher keiner Taktverschiebung unterworfen. Die Hauptanwendung ist die Messung der Leistung zwischen Intervallen:

ESMCJS

import { hrtime } from 'node:process'

const NS_PER_SEC = 1e9
const time = hrtime()
// [ 1800216, 25 ]

setTimeout(() => {
  const diff = hrtime(time)
  // [ 1, 552 ]

  console.log(`Benchmark dauerte ${diff[0] * NS_PER_SEC + diff[1]} Nanosekunden`)
  // Benchmark dauerte 1000000552 Nanosekunden
}, 1000)

const { hrtime } = require('node:process')

const NS_PER_SEC = 1e9
const time = hrtime()
// [ 1800216, 25 ]

setTimeout(() => {
  const diff = hrtime(time)
  // [ 1, 552 ]

  console.log(`Benchmark dauerte ${diff[0] * NS_PER_SEC + diff[1]} Nanosekunden`)
  // Benchmark dauerte 1000000552 Nanosekunden
}, 1000)

`process.hrtime.bigint()`

Hinzugefügt in: v10.7.0

Gibt zurück: <bigint>

Die bigint-Version der process.hrtime()-Methode, die die aktuelle hochauflösende Echtzeit in Nanosekunden als bigint zurückgibt.

Im Gegensatz zu process.hrtime() unterstützt sie kein zusätzliches time-Argument, da die Differenz einfach durch Subtraktion der beiden bigints direkt berechnet werden kann.

ESMCJS

import { hrtime } from 'node:process'

const start = hrtime.bigint()
// 191051479007711n

setTimeout(() => {
  const end = hrtime.bigint()
  // 191052633396993n

  console.log(`Benchmark dauerte ${end - start} Nanosekunden`)
  // Benchmark dauerte 1154389282 Nanosekunden
}, 1000)

const { hrtime } = require('node:process')

const start = hrtime.bigint()
// 191051479007711n

setTimeout(() => {
  const end = hrtime.bigint()
  // 191052633396993n

  console.log(`Benchmark dauerte ${end - start} Nanosekunden`)
  // Benchmark dauerte 1154389282 Nanosekunden
}, 1000)

`process.initgroups(user, extraGroup)`

Hinzugefügt in: v0.9.4

user <string> | <number> Der Benutzername oder die numerische Kennung.
extraGroup <string> | <number> Ein Gruppenname oder eine numerische Kennung.

Die Methode process.initgroups() liest die Datei /etc/group und initialisiert die Gruppenzugriffsliste unter Verwendung aller Gruppen, deren Mitglied der Benutzer ist. Dies ist eine privilegierte Operation, die erfordert, dass der Node.js-Prozess entweder root-Zugriff oder die CAP_SETGID-Funktion hat.

Seien Sie vorsichtig, wenn Sie Privilegien entfernen:

ESMCJS

import { getgroups, initgroups, setgid } from 'node:process'

console.log(getgroups()) // [ 0 ]
initgroups('nodeuser', 1000) // Benutzer wechseln
console.log(getgroups()) // [ 27, 30, 46, 1000, 0 ]
setgid(1000) // root gid entfernen
console.log(getgroups()) // [ 27, 30, 46, 1000 ]

const { getgroups, initgroups, setgid } = require('node:process')

console.log(getgroups()) // [ 0 ]
initgroups('nodeuser', 1000) // Benutzer wechseln
console.log(getgroups()) // [ 27, 30, 46, 1000, 0 ]
setgid(1000) // root gid entfernen
console.log(getgroups()) // [ 27, 30, 46, 1000 ]

Diese Funktion ist nur auf POSIX-Plattformen verfügbar (d. h. nicht Windows oder Android). Diese Funktion ist in Worker-Threads nicht verfügbar.

`process.kill(pid[, signal])`

Hinzugefügt in: v0.0.6

pid <number> Eine Prozess-ID
signal <string> | <number> Das zu sendende Signal, entweder als Zeichenkette oder Zahl. Standard: 'SIGTERM'.

Die Methode process.kill() sendet das signal an den Prozess, der durch pid identifiziert wird.

Signalnamen sind Zeichenketten wie 'SIGINT' oder 'SIGHUP'. Siehe Signalereignisse und kill(2) für weitere Informationen.

Diese Methode löst einen Fehler aus, wenn die Ziel-pid nicht existiert. Als Sonderfall kann ein Signal von 0 verwendet werden, um die Existenz eines Prozesses zu testen. Windows-Plattformen lösen einen Fehler aus, wenn die pid verwendet wird, um eine Prozessgruppe zu beenden.

Auch wenn der Name dieser Funktion process.kill() ist, ist sie eigentlich nur ein Signalsender, wie der Systemaufruf kill. Das gesendete Signal kann etwas anderes bewirken, als den Zielprozess zu beenden.

ESMCJS

import process, { kill } from 'node:process'

process.on('SIGHUP', () => {
  console.log('SIGHUP-Signal erhalten.')
})

setTimeout(() => {
  console.log('Beenden.')
  process.exit(0)
}, 100)

kill(process.pid, 'SIGHUP')

const process = require('node:process')

process.on('SIGHUP', () => {
  console.log('SIGHUP-Signal erhalten.')
})

setTimeout(() => {
  console.log('Beenden.')
  process.exit(0)
}, 100)

process.kill(process.pid, 'SIGHUP')

Wenn ein Node.js-Prozess SIGUSR1 empfängt, startet Node.js den Debugger. Siehe Signalereignisse.

`process.loadEnvFile(path)`

Hinzugefügt in: v21.7.0, v20.12.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1.1 - Aktive Entwicklung

path <string> | <URL> | <Buffer> | <undefined>. Standard: './.env'

Lädt die .env-Datei in process.env. Die Verwendung von NODE_OPTIONS in der .env-Datei hat keine Auswirkungen auf Node.js.

CJSESM

const { loadEnvFile } = require('node:process')
loadEnvFile()

import { loadEnvFile } from 'node:process'
loadEnvFile()

`process.mainModule`

Hinzugefügt in: v0.1.17

Veraltet seit: v14.0.0

[Stabil: 0 - Veraltet]

Stabil: 0 Stabilität: 0 - Veraltet: Verwenden Sie stattdessen require.main.

<Object>

Die Eigenschaft process.mainModule bietet eine alternative Möglichkeit, require.main abzurufen. Der Unterschied besteht darin, dass, wenn sich das Hauptmodul zur Laufzeit ändert, require.main immer noch auf das ursprüngliche Hauptmodul in Modulen verweisen kann, die vor der Änderung erforderlich waren. Im Allgemeinen kann man davon ausgehen, dass die beiden sich auf dasselbe Modul beziehen.

Wie bei require.main ist process.mainModule undefined, wenn kein Einstiegsskript vorhanden ist.

`process.memoryUsage()`

[Historie]

Version	Änderungen
v13.9.0, v12.17.0	`arrayBuffers` wurde zum zurückgegebenen Objekt hinzugefügt.
v7.2.0	`external` wurde zum zurückgegebenen Objekt hinzugefügt.
v0.1.16	Hinzugefügt in: v0.1.16

Gibt zurück: <Object>
- rss <integer>
- heapTotal <integer>
- heapUsed <integer>
- external <integer>
- arrayBuffers <integer>

Gibt ein Objekt zurück, das die Speichernutzung des Node.js-Prozesses in Bytes beschreibt.

ESMCJS

import { memoryUsage } from 'node:process'

console.log(memoryUsage())
// Gibt aus:
// {
//  rss: 4935680,
//  heapTotal: 1826816,
//  heapUsed: 650472,
//  external: 49879,
//  arrayBuffers: 9386
// }

const { memoryUsage } = require('node:process')

console.log(memoryUsage())
// Gibt aus:
// {
//  rss: 4935680,
//  heapTotal: 1826816,
//  heapUsed: 650472,
//  external: 49879,
//  arrayBuffers: 9386
// }

heapTotal und heapUsed beziehen sich auf die Speichernutzung von V8.
external bezieht sich auf die Speichernutzung von C++-Objekten, die an von V8 verwaltete JavaScript-Objekte gebunden sind.
rss, Resident Set Size, ist die Menge an Speicherplatz, die im Hauptspeichergerät (d. h. eine Teilmenge des gesamten zugewiesenen Speichers) für den Prozess belegt ist, einschließlich aller C++- und JavaScript-Objekte und -Codes.
arrayBuffers bezieht sich auf den Speicher, der für ArrayBuffers und SharedArrayBuffers zugewiesen wurde, einschließlich aller Node.js Buffers. Dies ist auch im Wert external enthalten. Wenn Node.js als eingebettete Bibliothek verwendet wird, kann dieser Wert 0 sein, da Zuweisungen für ArrayBuffers in diesem Fall möglicherweise nicht verfolgt werden.

Bei Verwendung von Worker-Threads ist rss ein Wert, der für den gesamten Prozess gültig ist, während sich die anderen Felder nur auf den aktuellen Thread beziehen.

Die Methode process.memoryUsage() durchläuft jede Seite, um Informationen über die Speichernutzung zu sammeln, was je nach Speicherzuweisungen des Programms langsam sein kann.

`process.memoryUsage.rss()`

Hinzugefügt in: v15.6.0, v14.18.0

Gibt zurück: <integer>

Die process.memoryUsage.rss()-Methode gibt eine Ganzzahl zurück, die die Resident Set Size (RSS) in Byte darstellt.

Die Resident Set Size ist der Speicherplatz, der im Hauptspeicher (also eine Teilmenge des gesamten zugewiesenen Speichers) für den Prozess belegt ist, einschließlich aller C++- und JavaScript-Objekte und -Codes.

Dies ist der gleiche Wert wie die rss-Eigenschaft, die von process.memoryUsage() bereitgestellt wird, aber process.memoryUsage.rss() ist schneller.

ESMCJS

import { memoryUsage } from 'node:process'

console.log(memoryUsage.rss())
// 35655680

const { memoryUsage } = require('node:process')

console.log(memoryUsage.rss())
// 35655680

`process.nextTick(callback[, ...args])`

[Verlauf]

Version	Änderungen
v22.7.0, v20.18.0	Stabilität auf Legacy geändert.
v18.0.0	Das Übergeben eines ungültigen Callbacks an das `callback`-Argument wirft jetzt `ERR_INVALID_ARG_TYPE` anstelle von `ERR_INVALID_CALLBACK`.
v1.8.1	Zusätzliche Argumente nach `callback` werden jetzt unterstützt.
v0.1.26	Hinzugefügt in: v0.1.26

[Stabil: 3 - Legacy]

Stabil: 3 Stabilität: 3 - Legacy: Verwenden Sie stattdessen queueMicrotask().

callback <Funktion>
...args <any> Zusätzliche Argumente, die beim Aufrufen des callbacks übergeben werden sollen.

process.nextTick() fügt callback der "Next-Tick-Warteschlange" hinzu. Diese Warteschlange wird vollständig geleert, nachdem der aktuelle Vorgang auf dem JavaScript-Stack abgeschlossen ist und bevor die Ereignisschleife fortgesetzt werden darf. Es ist möglich, eine Endlosschleife zu erstellen, wenn man rekursiv process.nextTick() aufrufen würde. Weitere Informationen finden Sie im Event Loop-Leitfaden.

ESMCJS

import { nextTick } from 'node:process'

console.log('start')
nextTick(() => {
  console.log('nextTick callback')
})
console.log('scheduled')
// Ausgabe:
// start
// scheduled
// nextTick callback

const { nextTick } = require('node:process')

console.log('start')
nextTick(() => {
  console.log('nextTick callback')
})
console.log('scheduled')
// Ausgabe:
// start
// scheduled
// nextTick callback

Dies ist wichtig bei der Entwicklung von APIs, um Benutzern die Möglichkeit zu geben, Ereignishandler nach der Konstruktion eines Objekts, aber vor dem Auftreten von E/A zuzuweisen:

ESMCJS

import { nextTick } from 'node:process'

function MyThing(options) {
  this.setupOptions(options)

  nextTick(() => {
    this.startDoingStuff()
  })
}

const thing = new MyThing()
thing.getReadyForStuff()

// thing.startDoingStuff() wird jetzt aufgerufen, nicht vorher.

const { nextTick } = require('node:process')

function MyThing(options) {
  this.setupOptions(options)

  nextTick(() => {
    this.startDoingStuff()
  })
}

const thing = new MyThing()
thing.getReadyForStuff()

// thing.startDoingStuff() wird jetzt aufgerufen, nicht vorher.

Es ist sehr wichtig, dass APIs entweder 100% synchron oder 100% asynchron sind. Betrachten Sie dieses Beispiel:

// WARNUNG! NICHT VERWENDEN! SCHLECHTE, UNSICHERE GEFAHR!
function maybeSync(arg, cb) {
  if (arg) {
    cb()
    return
  }

  fs.stat('file', cb)
}

Diese API ist gefährlich, da in folgendem Fall:

const maybeTrue = Math.random() > 0.5

maybeSync(maybeTrue, () => {
  foo()
})

bar()

Es ist nicht klar, ob foo() oder bar() zuerst aufgerufen werden.

Der folgende Ansatz ist viel besser:

ESMCJS

import { nextTick } from 'node:process'

function definitelyAsync(arg, cb) {
  if (arg) {
    nextTick(cb)
    return
  }

  fs.stat('file', cb)
}

const { nextTick } = require('node:process')

function definitelyAsync(arg, cb) {
  if (arg) {
    nextTick(cb)
    return
  }

  fs.stat('file', cb)
}

Wann `queueMicrotask()` vs. `process.nextTick()` verwenden

Die queueMicrotask()-API ist eine Alternative zu process.nextTick(), die auch die Ausführung einer Funktion mit derselben Mikroaufgaben-Warteschlange verschiebt, die verwendet wird, um die Then-, Catch- und Finally-Handler von aufgelösten Promises auszuführen. In Node.js wird jedes Mal, wenn die "Next-Tick-Warteschlange" geleert wird, die Mikroaufgaben-Warteschlange unmittelbar danach geleert.

ESMCJS

import { nextTick } from 'node:process'

Promise.resolve().then(() => console.log(2))
queueMicrotask(() => console.log(3))
nextTick(() => console.log(1))
// Ausgabe:
// 1
// 2
// 3

const { nextTick } = require('node:process')

Promise.resolve().then(() => console.log(2))
queueMicrotask(() => console.log(3))
nextTick(() => console.log(1))
// Ausgabe:
// 1
// 2
// 3

Für die meisten Anwendungsfälle im Userland bietet die queueMicrotask()-API einen portablen und zuverlässigen Mechanismus zur Verschiebung der Ausführung, der in mehreren JavaScript-Plattformumgebungen funktioniert und gegenüber process.nextTick() bevorzugt werden sollte. In einfachen Szenarien kann queueMicrotask() ein direkter Ersatz für process.nextTick() sein.

console.log('start')
queueMicrotask(() => {
  console.log('microtask callback')
})
console.log('scheduled')
// Ausgabe:
// start
// scheduled
// microtask callback

Ein bemerkenswerter Unterschied zwischen den beiden APIs besteht darin, dass process.nextTick() das Angeben zusätzlicher Werte ermöglicht, die als Argumente an die verzögerte Funktion übergeben werden, wenn sie aufgerufen wird. Um dasselbe Ergebnis mit queueMicrotask() zu erzielen, muss entweder eine Closure oder eine gebundene Funktion verwendet werden:

function deferred(a, b) {
  console.log('microtask', a + b)
}

console.log('start')
queueMicrotask(deferred.bind(undefined, 1, 2))
console.log('scheduled')
// Ausgabe:
// start
// scheduled
// microtask 3

Es gibt geringfügige Unterschiede in der Art und Weise, wie Fehler behandelt werden, die innerhalb der Next-Tick-Warteschlange und der Mikroaufgaben-Warteschlange auftreten. Fehler, die innerhalb eines in die Warteschlange gestellten Mikroaufgaben-Callbacks ausgelöst werden, sollten nach Möglichkeit innerhalb des in die Warteschlange gestellten Callbacks behandelt werden. Wenn dies nicht der Fall ist, kann der process.on('uncaughtException')-Ereignishandler verwendet werden, um die Fehler zu erfassen und zu behandeln.

Im Zweifelsfall, es sei denn, die spezifischen Fähigkeiten von process.nextTick() sind erforderlich, verwenden Sie queueMicrotask().

`process.noDeprecation`

Hinzugefügt in: v0.8.0

<boolean>

Die Eigenschaft process.noDeprecation gibt an, ob das Flag --no-deprecation im aktuellen Node.js-Prozess gesetzt ist. Weitere Informationen zum Verhalten dieses Flags finden Sie in der Dokumentation zum Ereignis 'warning' und zur Methode emitWarning().

`process.permission`

Hinzugefügt in: v20.0.0

<Object>

Diese API ist über das Flag --permission verfügbar.

process.permission ist ein Objekt, dessen Methoden zum Verwalten von Berechtigungen für den aktuellen Prozess verwendet werden. Zusätzliche Dokumentation ist im Berechtigungsmodell verfügbar.

`process.permission.has(scope[, reference])`

Hinzugefügt in: v20.0.0

scope <string>
reference <string>
Gibt zurück: <boolean>

Überprüft, ob der Prozess auf den gegebenen Bereich und die Referenz zugreifen kann. Wenn keine Referenz angegeben wird, wird ein globaler Bereich angenommen, z. B. process.permission.has('fs.read') prüft, ob der Prozess ALLE Dateisystem-Leseberechtigungen hat.

Die Referenz hat eine Bedeutung basierend auf dem angegebenen Bereich. Beispielsweise bedeutet die Referenz, wenn der Bereich Dateisystem ist, Dateien und Ordner.

Die verfügbaren Bereiche sind:

fs - Alle Dateisysteme
fs.read - Dateisystem-Leseoperationen
fs.write - Dateisystem-Schreiboperationen
child - Operationen zum Erzeugen von Kindprozessen
worker - Operation zum Erzeugen von Worker-Threads

// Überprüfen, ob der Prozess die Berechtigung zum Lesen der README-Datei hat
process.permission.has('fs.read', './README.md')
// Überprüfen, ob der Prozess über Leseberechtigungsoperationen verfügt
process.permission.has('fs.read')

`process.pid`

Hinzugefügt in: v0.1.15

<integer>

Die Eigenschaft process.pid gibt die PID des Prozesses zurück.

ESMCJS

import { pid } from 'node:process'

console.log(`Dieser Prozess hat die PID ${pid}`)

const { pid } = require('node:process')

console.log(`Dieser Prozess hat die PID ${pid}`)

`process.platform`

Hinzugefügt in: v0.1.16

<string>

Die Eigenschaft process.platform gibt eine Zeichenkette zurück, die die Betriebssystemplattform identifiziert, für die die Node.js-Binärdatei kompiliert wurde.

Aktuell mögliche Werte sind:

'aix'
'darwin'
'freebsd'
'linux'
'openbsd'
'sunos'
'win32'

ESMCJS

import { platform } from 'node:process'

console.log(`Diese Plattform ist ${platform}`)

const { platform } = require('node:process')

console.log(`Diese Plattform ist ${platform}`)

Der Wert 'android' kann auch zurückgegeben werden, wenn Node.js auf dem Android-Betriebssystem erstellt wurde. Die Android-Unterstützung in Node.js ist jedoch experimentell.

`process.ppid`

Hinzugefügt in: v9.2.0, v8.10.0, v6.13.0

<integer>

Die Eigenschaft process.ppid gibt die PID des übergeordneten Prozesses des aktuellen Prozesses zurück.

ESMCJS

import { ppid } from 'node:process'

console.log(`Der übergeordnete Prozess hat die PID ${ppid}`)

const { ppid } = require('node:process')

console.log(`Der übergeordnete Prozess hat die PID ${ppid}`)

`process.release`

[Historie]

Version	Änderungen
v4.2.0	Die `lts`-Eigenschaft wird nun unterstützt.
v3.0.0	Hinzugefügt in: v3.0.0

<Object>

Die Eigenschaft process.release gibt ein Object zurück, das Metadaten zur aktuellen Version enthält, einschließlich URLs für die Quellcode- und Header-Only-Tarballs.

process.release enthält die folgenden Eigenschaften:

name <string> Ein Wert, der immer 'node' ist.
sourceUrl <string> Eine absolute URL, die auf eine .tar.gz-Datei verweist, die den Quellcode der aktuellen Version enthält.
headersUrl<string> Eine absolute URL, die auf eine .tar.gz-Datei verweist, die nur die Quellheaderdateien für die aktuelle Version enthält. Diese Datei ist erheblich kleiner als die vollständige Quelldatei und kann zum Kompilieren nativer Node.js-Add-ons verwendet werden.
libUrl <string> | <undefined> Eine absolute URL, die auf eine node.lib-Datei verweist, die der Architektur und der Version der aktuellen Version entspricht. Diese Datei wird zum Kompilieren nativer Node.js-Add-ons verwendet. Diese Eigenschaft ist nur in Windows-Builds von Node.js vorhanden und fehlt auf allen anderen Plattformen.
lts <string> | <undefined> Eine Zeichenkettenbezeichnung, die die LTS-Bezeichnung für diese Version identifiziert. Diese Eigenschaft existiert nur für LTS-Versionen und ist für alle anderen Versionstypen, einschließlich aktuelle Versionen, undefined. Gültige Werte sind die Codenamen der LTS-Versionen (einschließlich derjenigen, die nicht mehr unterstützt werden).
- 'Fermium' für die 14.x LTS-Linie ab 14.15.0.
- 'Gallium' für die 16.x LTS-Linie ab 16.13.0.
- 'Hydrogen' für die 18.x LTS-Linie ab 18.12.0. Weitere Codenamen von LTS-Versionen finden Sie im Node.js Changelog Archive

{
  name: 'node',
  lts: 'Hydrogen',
  sourceUrl: 'https://nodejs.org/download/release/v18.12.0/node-v18.12.0.tar.gz',
  headersUrl: 'https://nodejs.org/download/release/v18.12.0/node-v18.12.0-headers.tar.gz',
  libUrl: 'https://nodejs.org/download/release/v18.12.0/win-x64/node.lib'
}

In benutzerdefinierten Builds aus Nicht-Release-Versionen des Quellcodebaums ist möglicherweise nur die name-Eigenschaft vorhanden. Die zusätzlichen Eigenschaften sollten nicht als vorhanden angenommen werden.

`process.report`

[Verlauf]

Version	Änderungen
v13.12.0, v12.17.0	Diese API ist nicht mehr experimentell.
v11.8.0	Hinzugefügt in: v11.8.0

<Object>

process.report ist ein Objekt, dessen Methoden verwendet werden, um Diagnoseberichte für den aktuellen Prozess zu erstellen. Zusätzliche Dokumentation ist in der Berichtsdokumentation verfügbar.

`process.report.compact`

Hinzugefügt in: v13.12.0, v12.17.0

<boolean>

Schreibt Berichte in einem kompakten Format, einzeiliges JSON, das von Log-Verarbeitungssystemen leichter verarbeitet werden kann als das standardmäßige mehrzeilige Format, das für den menschlichen Gebrauch entwickelt wurde.

ESMCJS

import { report } from 'node:process'

console.log(`Sind Berichte kompakt? ${report.compact}`)

const { report } = require('node:process')

console.log(`Sind Berichte kompakt? ${report.compact}`)

`process.report.directory`

[Verlauf]

Version	Änderungen
v13.12.0, v12.17.0	Diese API ist nicht mehr experimentell.
v11.12.0	Hinzugefügt in: v11.12.0

<string>

Verzeichnis, in das der Bericht geschrieben wird. Der Standardwert ist die leere Zeichenkette, die angibt, dass Berichte in das aktuelle Arbeitsverzeichnis des Node.js-Prozesses geschrieben werden.

ESMCJS

import { report } from 'node:process'

console.log(`Das Berichtsverzeichnis ist ${report.directory}`)

const { report } = require('node:process')

console.log(`Das Berichtsverzeichnis ist ${report.directory}`)

`process.report.filename`

[Verlauf]

Version	Änderungen
v13.12.0, v12.17.0	Diese API ist nicht mehr experimentell.
v11.12.0	Hinzugefügt in: v11.12.0

<string>

Dateiname, in den der Bericht geschrieben wird. Wenn er auf die leere Zeichenkette gesetzt ist, besteht der Ausgabedateiname aus einem Zeitstempel, einer PID und einer Sequenznummer. Der Standardwert ist die leere Zeichenkette.

Wenn der Wert von process.report.filename auf 'stdout' oder 'stderr' gesetzt ist, wird der Bericht auf die Standardausgabe bzw. Standardfehlerausgabe des Prozesses geschrieben.

ESMCJS

import { report } from 'node:process'

console.log(`Der Berichtsdateiname ist ${report.filename}`)

const { report } = require('node:process')

console.log(`Der Berichtsdateiname ist ${report.filename}`)

`process.report.getReport([err])`

[Verlauf]

Version	Änderungen
v13.12.0, v12.17.0	Diese API ist nicht mehr experimentell.
v11.8.0	Hinzugefügt in: v11.8.0

err <Error> Ein benutzerdefinierter Fehler, der für die Berichterstattung über den JavaScript-Stack verwendet wird.
Gibt zurück: <Object>

Gibt eine JavaScript-Objektdarstellung eines Diagnoseberichts für den laufenden Prozess zurück. Die JavaScript-Stack-Trace des Berichts wird aus err entnommen, falls vorhanden.

ESMCJS

import { report } from 'node:process'
import util from 'node:util'

const data = report.getReport()
console.log(data.header.nodejsVersion)

// Ähnlich wie process.report.writeReport()
import fs from 'node:fs'
fs.writeFileSync('my-report.log', util.inspect(data), 'utf8')

const { report } = require('node:process')
const util = require('node:util')

const data = report.getReport()
console.log(data.header.nodejsVersion)

// Ähnlich wie process.report.writeReport()
const fs = require('node:fs')
fs.writeFileSync('my-report.log', util.inspect(data), 'utf8')

Zusätzliche Dokumentation ist in der Berichtsdokumentation verfügbar.

`process.report.reportOnFatalError`

[Verlauf]

Version	Änderungen
v15.0.0, v14.17.0	Diese API ist nicht mehr experimentell.
v11.12.0	Hinzugefügt in: v11.12.0

<boolean>

Wenn true, wird ein Diagnosebericht bei schwerwiegenden Fehlern generiert, z. B. bei Speichermangel oder fehlgeschlagenen C++-Assertionen.

ESMCJS

import { report } from 'node:process'

console.log(`Bericht über schwerwiegende Fehler: ${report.reportOnFatalError}`)

const { report } = require('node:process')

console.log(`Bericht über schwerwiegende Fehler: ${report.reportOnFatalError}`)

`process.report.reportOnSignal`

[Historie]

Version	Änderungen
v13.12.0, v12.17.0	Diese API ist nicht mehr experimentell.
v11.12.0	Hinzugefügt in: v11.12.0

<boolean>

Wenn true, wird ein Diagnosebericht generiert, wenn der Prozess das durch process.report.signal angegebene Signal empfängt.

ESMCJS

import { report } from 'node:process'

console.log(`Bericht zum Signal: ${report.reportOnSignal}`)

const { report } = require('node:process')

console.log(`Bericht zum Signal: ${report.reportOnSignal}`)

`process.report.reportOnUncaughtException`

[Historie]

Version	Änderungen
v13.12.0, v12.17.0	Diese API ist nicht mehr experimentell.
v11.12.0	Hinzugefügt in: v11.12.0

<boolean>

Wenn true, wird ein Diagnosebericht bei nicht abgefangenen Ausnahmen generiert.

ESMCJS

import { report } from 'node:process'

console.log(`Bericht zur Ausnahme: ${report.reportOnUncaughtException}`)

const { report } = require('node:process')

console.log(`Bericht zur Ausnahme: ${report.reportOnUncaughtException}`)

`process.report.excludeEnv`

Hinzugefügt in: v23.3.0

<boolean>

Wenn true, wird ein Diagnosebericht ohne die Umgebungsvariablen generiert.

`process.report.signal`

[Historie]

Version	Änderungen
v13.12.0, v12.17.0	Diese API ist nicht mehr experimentell.
v11.12.0	Hinzugefügt in: v11.12.0

<string>

Das Signal, das verwendet wird, um die Erstellung eines Diagnoseberichts auszulösen. Standardmäßig 'SIGUSR2'.

ESMCJS

import { report } from 'node:process'

console.log(`Berichtssignal: ${report.signal}`)

const { report } = require('node:process')

console.log(`Berichtssignal: ${report.signal}`)

`process.report.writeReport([filename][, err])`

[Verlauf]

Version	Änderungen
v13.12.0, v12.17.0	Diese API ist nicht mehr experimentell.
v11.8.0	Hinzugefügt in: v11.8.0

filename <string> Name der Datei, in die der Bericht geschrieben wird. Dies sollte ein relativer Pfad sein, der an das in process.report.directory angegebene Verzeichnis angehängt wird, oder an das aktuelle Arbeitsverzeichnis des Node.js-Prozesses, falls nicht angegeben.
err <Error> Ein benutzerdefinierter Fehler, der für die Meldung des JavaScript-Stacks verwendet wird.
Gibt zurück: <string> Gibt den Dateinamen des generierten Berichts zurück.

Schreibt einen Diagnosebericht in eine Datei. Wenn filename nicht angegeben wird, enthält der Standarddateiname das Datum, die Uhrzeit, die PID und eine Sequenznummer. Die JavaScript-Stack-Trace des Berichts stammt von err, falls vorhanden.

Wenn der Wert von filename auf 'stdout' oder 'stderr' gesetzt ist, wird der Bericht in die Standardausgabe bzw. Standardfehlerausgabe des Prozesses geschrieben.

ESMCJS

import { report } from 'node:process'

report.writeReport()

const { report } = require('node:process')

report.writeReport()

Weitere Dokumentation finden Sie in der Berichtsdokumentation.

`process.resourceUsage()`

Hinzugefügt in: v12.6.0

Gibt zurück: <Object> die Ressourcenauslastung für den aktuellen Prozess. Alle diese Werte stammen aus dem Aufruf uv_getrusage, der eine uv_rusage_t-Struktur zurückgibt.
- userCPUTime <integer> bildet ru_utime ab, berechnet in Mikrosekunden. Es ist der gleiche Wert wie process.cpuUsage().user.
- systemCPUTime <integer> bildet ru_stime ab, berechnet in Mikrosekunden. Es ist der gleiche Wert wie process.cpuUsage().system.
- maxRSS <integer> bildet ru_maxrss ab, was die maximale verwendete Resident Set Size in Kilobyte ist.
- sharedMemorySize <integer> bildet ru_ixrss ab, wird aber von keiner Plattform unterstützt.
- unsharedDataSize <integer> bildet ru_idrss ab, wird aber von keiner Plattform unterstützt.
- unsharedStackSize <integer> bildet ru_isrss ab, wird aber von keiner Plattform unterstützt.
- minorPageFault <integer> bildet ru_minflt ab, was die Anzahl der geringfügigen Seitenfehler für den Prozess ist, siehe diesen Artikel für weitere Details.
- majorPageFault <integer> bildet ru_majflt ab, was die Anzahl der schwerwiegenden Seitenfehler für den Prozess ist, siehe diesen Artikel für weitere Details. Dieses Feld wird unter Windows nicht unterstützt.
- swappedOut <integer> bildet ru_nswap ab, wird aber von keiner Plattform unterstützt.
- fsRead <integer> bildet ru_inblock ab, was die Anzahl der Male ist, die das Dateisystem Eingaben ausführen musste.
- fsWrite <integer> bildet ru_oublock ab, was die Anzahl der Male ist, die das Dateisystem Ausgaben ausführen musste.
- ipcSent <integer> bildet ru_msgsnd ab, wird aber von keiner Plattform unterstützt.
- ipcReceived <integer> bildet ru_msgrcv ab, wird aber von keiner Plattform unterstützt.
- signalsCount <integer> bildet ru_nsignals ab, wird aber von keiner Plattform unterstützt.
- voluntaryContextSwitches <integer> bildet ru_nvcsw ab, was die Anzahl der Male ist, die ein CPU-Kontextwechsel erfolgte, weil ein Prozess den Prozessor freiwillig vor Abschluss seines Zeitschlitzes aufgegeben hat (normalerweise, um die Verfügbarkeit einer Ressource abzuwarten). Dieses Feld wird unter Windows nicht unterstützt.
- involuntaryContextSwitches <integer> bildet ru_nivcsw ab, was die Anzahl der Male ist, die ein CPU-Kontextwechsel erfolgte, weil ein Prozess mit höherer Priorität ausführbar wurde oder weil der aktuelle Prozess seinen Zeitschlitz überschritten hat. Dieses Feld wird unter Windows nicht unterstützt.

ESMCJS

import { resourceUsage } from 'node:process'

console.log(resourceUsage())
/*
  Wird ausgeben:
  {
    userCPUTime: 82872,
    systemCPUTime: 4143,
    maxRSS: 33164,
    sharedMemorySize: 0,
    unsharedDataSize: 0,
    unsharedStackSize: 0,
    minorPageFault: 2469,
    majorPageFault: 0,
    swappedOut: 0,
    fsRead: 0,
    fsWrite: 8,
    ipcSent: 0,
    ipcReceived: 0,
    signalsCount: 0,
    voluntaryContextSwitches: 79,
    involuntaryContextSwitches: 1
  }
*/

const { resourceUsage } = require('node:process')

console.log(resourceUsage())
/*
  Wird ausgeben:
  {
    userCPUTime: 82872,
    systemCPUTime: 4143,
    maxRSS: 33164,
    sharedMemorySize: 0,
    unsharedDataSize: 0,
    unsharedStackSize: 0,
    minorPageFault: 2469,
    majorPageFault: 0,
    swappedOut: 0,
    fsRead: 0,
    fsWrite: 8,
    ipcSent: 0,
    ipcReceived: 0,
    signalsCount: 0,
    voluntaryContextSwitches: 79,
    involuntaryContextSwitches: 1
  }
*/

`process.send(message[, sendHandle[, options]][, callback])`

Hinzugefügt in: v0.5.9

message <Object>
sendHandle <net.Server> | <net.Socket>
options <Object>, wird verwendet, um das Senden bestimmter Handle-Typen zu parametrisieren. options unterstützt die folgenden Eigenschaften:
- keepOpen <boolean> Ein Wert, der beim Übergeben von Instanzen von net.Socket verwendet werden kann. Wenn true, wird der Socket im sendenden Prozess offen gehalten. Standard: false.
callback <Function>
Gibt zurück: <boolean>

Wenn Node.js mit einem IPC-Kanal gestartet wird, kann die process.send()-Methode verwendet werden, um Nachrichten an den übergeordneten Prozess zu senden. Nachrichten werden als 'message'-Ereignis auf dem ChildProcess-Objekt des übergeordneten Prozesses empfangen.

Wenn Node.js nicht mit einem IPC-Kanal gestartet wurde, ist process.send undefined.

Die Nachricht durchläuft eine Serialisierung und Analyse. Die resultierende Nachricht ist möglicherweise nicht dieselbe wie die ursprünglich gesendete.

`process.setegid(id)`

Hinzugefügt in: v2.0.0

id <string> | <number> Ein Gruppenname oder eine ID

Die process.setegid()-Methode setzt die effektive Gruppenidentität des Prozesses. (Siehe setegid(2).) Die id kann entweder als numerische ID oder als Gruppenname-String übergeben werden. Wenn ein Gruppenname angegeben wird, blockiert diese Methode, während die zugehörige numerische ID aufgelöst wird.

ESMCJS

import process from 'node:process'

if (process.getegid && process.setegid) {
  console.log(`Aktuelle gid: ${process.getegid()}`)
  try {
    process.setegid(501)
    console.log(`Neue gid: ${process.getegid()}`)
  } catch (err) {
    console.error(`Fehler beim Setzen der gid: ${err}`)
  }
}

const process = require('node:process')

if (process.getegid && process.setegid) {
  console.log(`Aktuelle gid: ${process.getegid()}`)
  try {
    process.setegid(501)
    console.log(`Neue gid: ${process.getegid()}`)
  } catch (err) {
    console.error(`Fehler beim Setzen der gid: ${err}`)
  }
}

Diese Funktion ist nur auf POSIX-Plattformen verfügbar (d. h. nicht Windows oder Android). Diese Funktion ist in Worker-Threads nicht verfügbar.

`process.seteuid(id)`

Hinzugefügt in: v2.0.0

id <string> | <number> Ein Benutzername oder eine ID

Die Methode process.seteuid() setzt die effektive Benutzeridentität des Prozesses. (Siehe seteuid(2).) Die id kann entweder als numerische ID oder als Benutzername-String übergeben werden. Wenn ein Benutzername angegeben wird, blockiert die Methode, während die zugehörige numerische ID aufgelöst wird.

ESMCJS

import process from 'node:process'

if (process.geteuid && process.seteuid) {
  console.log(`Aktuelle uid: ${process.geteuid()}`)
  try {
    process.seteuid(501)
    console.log(`Neue uid: ${process.geteuid()}`)
  } catch (err) {
    console.error(`Fehler beim Setzen der uid: ${err}`)
  }
}

const process = require('node:process')

if (process.geteuid && process.seteuid) {
  console.log(`Aktuelle uid: ${process.geteuid()}`)
  try {
    process.seteuid(501)
    console.log(`Neue uid: ${process.geteuid()}`)
  } catch (err) {
    console.error(`Fehler beim Setzen der uid: ${err}`)
  }
}

Diese Funktion ist nur auf POSIX-Plattformen verfügbar (d. h. nicht unter Windows oder Android). Diese Funktion ist in Worker-Threads nicht verfügbar.

`process.setgid(id)`

Hinzugefügt in: v0.1.31

id <string> | <number> Der Gruppenname oder die ID

Die Methode process.setgid() setzt die Gruppenidentität des Prozesses. (Siehe setgid(2).) Die id kann entweder als numerische ID oder als Gruppenname-String übergeben werden. Wenn ein Gruppenname angegeben wird, blockiert diese Methode, während die zugehörige numerische ID aufgelöst wird.

ESMCJS

import process from 'node:process'

if (process.getgid && process.setgid) {
  console.log(`Aktuelle gid: ${process.getgid()}`)
  try {
    process.setgid(501)
    console.log(`Neue gid: ${process.getgid()}`)
  } catch (err) {
    console.error(`Fehler beim Setzen der gid: ${err}`)
  }
}

const process = require('node:process')

if (process.getgid && process.setgid) {
  console.log(`Aktuelle gid: ${process.getgid()}`)
  try {
    process.setgid(501)
    console.log(`Neue gid: ${process.getgid()}`)
  } catch (err) {
    console.error(`Fehler beim Setzen der gid: ${err}`)
  }
}

Diese Funktion ist nur auf POSIX-Plattformen verfügbar (d. h. nicht unter Windows oder Android). Diese Funktion ist in Worker-Threads nicht verfügbar.

`process.setgroups(groups)`

Hinzugefügt in: v0.9.4

groups <integer[]>

Die Methode process.setgroups() legt die zusätzlichen Gruppen-IDs für den Node.js-Prozess fest. Dies ist eine privilegierte Operation, die erfordert, dass der Node.js-Prozess root- oder die CAP_SETGID-Fähigkeit besitzt.

Das groups-Array kann numerische Gruppen-IDs, Gruppennamen oder beides enthalten.

ESMCJS

import process from 'node:process'

if (process.getgroups && process.setgroups) {
  try {
    process.setgroups([501])
    console.log(process.getgroups()) // neue Gruppen
  } catch (err) {
    console.error(`Fehler beim Setzen der Gruppen: ${err}`)
  }
}

const process = require('node:process')

if (process.getgroups && process.setgroups) {
  try {
    process.setgroups([501])
    console.log(process.getgroups()) // neue Gruppen
  } catch (err) {
    console.error(`Fehler beim Setzen der Gruppen: ${err}`)
  }
}

Diese Funktion ist nur auf POSIX-Plattformen verfügbar (d. h. nicht Windows oder Android). Diese Funktion ist in Worker-Threads nicht verfügbar.

`process.setuid(id)`

Hinzugefügt in: v0.1.28

id <integer> | <string>

Die Methode process.setuid(id) legt die Benutzeridentität des Prozesses fest. (Siehe setuid(2).) Die id kann entweder als numerische ID oder als Benutzername-String übergeben werden. Wenn ein Benutzername angegeben wird, blockiert die Methode, während die zugehörige numerische ID aufgelöst wird.

ESMCJS

import process from 'node:process'

if (process.getuid && process.setuid) {
  console.log(`Aktuelle uid: ${process.getuid()}`)
  try {
    process.setuid(501)
    console.log(`Neue uid: ${process.getuid()}`)
  } catch (err) {
    console.error(`Fehler beim Setzen der uid: ${err}`)
  }
}

const process = require('node:process')

if (process.getuid && process.setuid) {
  console.log(`Aktuelle uid: ${process.getuid()}`)
  try {
    process.setuid(501)
    console.log(`Neue uid: ${process.getuid()}`)
  } catch (err) {
    console.error(`Fehler beim Setzen der uid: ${err}`)
  }
}

Diese Funktion ist nur auf POSIX-Plattformen verfügbar (d. h. nicht Windows oder Android). Diese Funktion ist in Worker-Threads nicht verfügbar.

`process.setSourceMapsEnabled(val)`

Hinzugefügt in: v16.6.0, v14.18.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

val <boolean>

Diese Funktion aktiviert oder deaktiviert die Source Map v3-Unterstützung für Stacktraces.

Sie bietet die gleichen Funktionen wie das Starten des Node.js-Prozesses mit der Kommandozeilenoption --enable-source-maps.

Es werden nur Source Maps in JavaScript-Dateien analysiert und geladen, die geladen werden, nachdem Source Maps aktiviert wurden.

`process.setUncaughtExceptionCaptureCallback(fn)`

Hinzugefügt in: v9.3.0

fn <Function> | <null>

Die Funktion process.setUncaughtExceptionCaptureCallback() legt eine Funktion fest, die aufgerufen wird, wenn eine nicht abgefangene Ausnahme auftritt und den Ausnahmewert selbst als erstes Argument erhält.

Wenn eine solche Funktion gesetzt ist, wird das Ereignis 'uncaughtException' nicht ausgelöst. Wenn --abort-on-uncaught-exception von der Befehlszeile übergeben oder durch v8.setFlagsFromString() festgelegt wurde, wird der Prozess nicht abgebrochen. Aktionen, die bei Ausnahmen ausgeführt werden sollen, wie z. B. die Generierung von Berichten, sind ebenfalls betroffen.

Um die Erfassungsfunktion aufzuheben, kann process.setUncaughtExceptionCaptureCallback(null) verwendet werden. Das Aufrufen dieser Methode mit einem nicht-null-Argument, während eine andere Erfassungsfunktion festgelegt ist, wirft einen Fehler.

Die Verwendung dieser Funktion schließt die Verwendung des veralteten integrierten Moduls domain aus.

`process.sourceMapsEnabled`

Hinzugefügt in: v20.7.0, v18.19.0

[Stabil: 1 - Experimentell]

Stabil: 1 Stabilität: 1 - Experimentell

<boolean>

Die Eigenschaft process.sourceMapsEnabled gibt zurück, ob die Source Map v3-Unterstützung für Stacktraces aktiviert ist.

`process.stderr`

<Stream>

Die Eigenschaft process.stderr gibt einen Stream zurück, der mit stderr (fd 2) verbunden ist. Es handelt sich um einen net.Socket (der ein Duplex Stream ist), es sei denn, fd 2 verweist auf eine Datei. In diesem Fall ist es ein Writable Stream.

process.stderr unterscheidet sich in wichtigen Punkten von anderen Node.js Streams. Weitere Informationen finden Sie im Hinweis zu Prozess-I/O.

`process.stderr.fd`

<number>

Diese Eigenschaft bezieht sich auf den Wert des zugrunde liegenden Dateideskriptors von process.stderr. Der Wert ist auf 2 festgelegt. In Worker Threads existiert dieses Feld nicht.

`process.stdin`

<Stream>

Die Eigenschaft process.stdin gibt einen Stream zurück, der mit stdin (fd 0) verbunden ist. Es handelt sich um einen net.Socket (der ein Duplex Stream ist), es sei denn, fd 0 verweist auf eine Datei. In diesem Fall ist es ein Readable Stream.

Einzelheiten zum Lesen von stdin finden Sie unter readable.read().

Als Duplex Stream kann process.stdin auch im "alten" Modus verwendet werden, der mit Skripten kompatibel ist, die vor Node.js v0.10 geschrieben wurden. Weitere Informationen finden Sie unter Stream-Kompatibilität.

Im "alten" Stream-Modus ist der stdin-Stream standardmäßig pausiert, daher muss man process.stdin.resume() aufrufen, um daraus zu lesen. Beachten Sie auch, dass der Aufruf von process.stdin.resume() selbst den Stream in den "alten" Modus schalten würde.

`process.stdin.fd`

<number>

Diese Eigenschaft bezieht sich auf den Wert des zugrunde liegenden Dateideskriptors von process.stdin. Der Wert ist auf 0 festgelegt. In Worker Threads existiert dieses Feld nicht.

`process.stdout`

<Stream>

Die Eigenschaft process.stdout gibt einen Stream zurück, der mit stdout (fd 1) verbunden ist. Es handelt sich um einen net.Socket (der ein Duplex-Stream ist), es sei denn, fd 1 verweist auf eine Datei. In diesem Fall handelt es sich um einen Writable-Stream.

Um beispielsweise process.stdin nach process.stdout zu kopieren:

ESMCJS

import { stdin, stdout } from 'node:process'

stdin.pipe(stdout)

const { stdin, stdout } = require('node:process')

stdin.pipe(stdout)

process.stdout unterscheidet sich in wichtigen Punkten von anderen Node.js-Streams. Weitere Informationen finden Sie im Hinweis zu Prozess-I/O.

`process.stdout.fd`

<number>

Diese Eigenschaft bezieht sich auf den Wert des zugrunde liegenden Dateideskriptors von process.stdout. Der Wert ist fest auf 1 gesetzt. In Worker-Threads existiert dieses Feld nicht.

Ein Hinweis zu Prozess-I/O

process.stdout und process.stderr unterscheiden sich in wichtigen Punkten von anderen Node.js-Streams:

Diese Verhaltensweisen haben zum Teil historische Gründe, da eine Änderung eine Abwärtsinkompatibilität verursachen würde, sie werden aber auch von einigen Benutzern erwartet.

Synchrones Schreiben vermeidet Probleme, wie z. B. die unerwartete Verschränkung von Ausgaben, die mit console.log() oder console.error() geschrieben wurden, oder dass sie gar nicht geschrieben werden, wenn process.exit() aufgerufen wird, bevor ein asynchroner Schreibvorgang abgeschlossen ist. Weitere Informationen finden Sie unter process.exit().

Warnung: Synchrones Schreiben blockiert die Ereignisschleife, bis der Schreibvorgang abgeschlossen ist. Dies kann bei der Ausgabe in eine Datei nahezu augenblicklich erfolgen, aber unter hoher Systemlast, bei Pipes, die am empfangenden Ende nicht gelesen werden, oder bei langsamen Terminals oder Dateisystemen kann es vorkommen, dass die Ereignisschleife häufig und lange genug blockiert wird, um erhebliche negative Auswirkungen auf die Leistung zu haben. Dies kann bei der Ausgabe auf eine interaktive Terminal-Sitzung kein Problem darstellen, aber seien Sie besonders vorsichtig, wenn Sie in der Produktion in die Prozessausgabeströme protokollieren.

Um zu überprüfen, ob ein Stream mit einem TTY-Kontext verbunden ist, überprüfen Sie die Eigenschaft isTTY.

Zum Beispiel:

bash

$ node -p "Boolean(process.stdin.isTTY)"
true
$ echo "foo" | node -p "Boolean(process.stdin.isTTY)"
false
$ node -p "Boolean(process.stdout.isTTY)"
true
$ node -p "Boolean(process.stdout.isTTY)" | cat
false

Weitere Informationen finden Sie in der TTY-Dokumentation.

`process.throwDeprecation`

Hinzugefügt in: v0.9.12

<boolean>

Der Anfangswert von process.throwDeprecation gibt an, ob das Flag --throw-deprecation im aktuellen Node.js-Prozess gesetzt ist. process.throwDeprecation ist veränderbar, sodass es zur Laufzeit geändert werden kann, ob Veraltungswarnungen zu Fehlern führen oder nicht. Weitere Informationen finden Sie in der Dokumentation zum 'warning'-Ereignis und der emitWarning()-Methode.

bash

$ node --throw-deprecation -p "process.throwDeprecation"
true
$ node -p "process.throwDeprecation"
undefined
$ node
> process.emitWarning('test', 'DeprecationWarning');
undefined
> (node:26598) DeprecationWarning: test
> process.throwDeprecation = true;
true
> process.emitWarning('test', 'DeprecationWarning');
Ausgeworfen:
[DeprecationWarning: test] { name: 'DeprecationWarning' }

`process.title`

Hinzugefügt in: v0.1.104

<string>

Die Eigenschaft process.title gibt den aktuellen Prozesstitel zurück (d. h. den aktuellen Wert von ps). Das Zuweisen eines neuen Werts zu process.title ändert den aktuellen Wert von ps.

Beim Zuweisen eines neuen Wertes werden von verschiedenen Plattformen unterschiedliche maximale Längenbeschränkungen für den Titel auferlegt. Normalerweise sind diese Einschränkungen recht begrenzt. Auf Linux und macOS beispielsweise ist process.title auf die Größe des binären Namens plus die Länge der Befehlszeilenargumente beschränkt, da das Setzen von process.title den argv-Speicher des Prozesses überschreibt. Node.js v0.8 erlaubte längere Prozesstitelstrings, indem auch der environ-Speicher überschrieben wurde, was jedoch in einigen (eher obskuren) Fällen potenziell unsicher und verwirrend war.

Das Zuweisen eines Wertes zu process.title führt möglicherweise nicht zu einer genauen Beschriftung in Prozessmanageranwendungen wie macOS Activity Monitor oder Windows Services Manager.

`process.traceDeprecation`

Hinzugefügt in: v0.8.0

<boolean>

Die Eigenschaft process.traceDeprecation gibt an, ob das Flag --trace-deprecation im aktuellen Node.js-Prozess gesetzt ist. Weitere Informationen zum Verhalten dieses Flags finden Sie in der Dokumentation zum 'warning'-Ereignis und zur emitWarning()-Methode.

`process.umask()`

[Verlauf]

Version	Änderungen
v14.0.0, v12.19.0	Das Aufrufen von `process.umask()` ohne Argumente ist veraltet.
v0.1.19	Hinzugefügt in: v0.1.19

[Stabil: 0 - Veraltet]

Stabil: 0 Stabilität: 0 - Veraltet. Das Aufrufen von process.umask() ohne Argumente führt dazu, dass die prozessweite Umask zweimal geschrieben wird. Dies führt zu einer Race Condition zwischen Threads und ist eine potenzielle Sicherheitslücke. Es gibt keine sichere, plattformübergreifende Alternative API.

process.umask() gibt die Dateimodus-Erstellungsmaske des Node.js-Prozesses zurück. Kindprozesse erben die Maske vom Elternprozess.

`process.umask(mask)`

Hinzugefügt in: v0.1.19

mask <string> | <integer>

process.umask(mask) setzt die Dateimodus-Erstellungsmaske des Node.js-Prozesses. Kindprozesse erben die Maske vom Elternprozess. Gibt die vorherige Maske zurück.

ESMCJS

import { umask } from 'node:process'

const newmask = 0o022
const oldmask = umask(newmask)
console.log(`Geänderte umask von ${oldmask.toString(8)} zu ${newmask.toString(8)}`)

const { umask } = require('node:process')

const newmask = 0o022
const oldmask = umask(newmask)
console.log(`Geänderte umask von ${oldmask.toString(8)} zu ${newmask.toString(8)}`)

In Worker-Threads wirft process.umask(mask) eine Ausnahme.

`process.uptime()`

Hinzugefügt in: v0.5.0

Gibt zurück: <number>

Die process.uptime()-Methode gibt die Anzahl der Sekunden zurück, die der aktuelle Node.js-Prozess bereits läuft.

Der Rückgabewert enthält Bruchteile einer Sekunde. Verwenden Sie Math.floor(), um ganze Sekunden zu erhalten.

`process.version`

Hinzugefügt in: v0.1.3

<string>

Die process.version-Eigenschaft enthält die Node.js-Versionszeichenfolge.

ESMCJS

import { version } from 'node:process'

console.log(`Version: ${version}`)
// Version: v14.8.0

const { version } = require('node:process')

console.log(`Version: ${version}`)
// Version: v14.8.0

Um die Versionszeichenfolge ohne das vorangestellte v zu erhalten, verwenden Sie process.versions.node.

`process.versions`

[Verlauf]

Version	Änderungen
v9.0.0	Die `v8`-Eigenschaft enthält nun ein Node.js-spezifisches Suffix.
v4.2.0	Die `icu`-Eigenschaft wird jetzt unterstützt.
v0.2.0	Hinzugefügt in: v0.2.0

<Object>

Die process.versions-Eigenschaft gibt ein Objekt zurück, das die Versionszeichenfolgen von Node.js und seinen Abhängigkeiten auflistet. process.versions.modules gibt die aktuelle ABI-Version an, die erhöht wird, wenn sich eine C++-API ändert. Node.js weigert sich, Module zu laden, die gegen eine andere Modul-ABI-Version kompiliert wurden.

ESMCJS

import { versions } from 'node:process'

console.log(versions)

const { versions } = require('node:process')

console.log(versions)

Erzeugt ein Objekt ähnlich wie:

bash

{ node: '23.0.0',
  acorn: '8.11.3',
  ada: '2.7.8',
  ares: '1.28.1',
  base64: '0.5.2',
  brotli: '1.1.0',
  cjs_module_lexer: '1.2.2',
  cldr: '45.0',
  icu: '75.1',
  llhttp: '9.2.1',
  modules: '127',
  napi: '9',
  nghttp2: '1.61.0',
  nghttp3: '0.7.0',
  ngtcp2: '1.3.0',
  openssl: '3.0.13+quic',
  simdjson: '3.8.0',
  simdutf: '5.2.4',
  sqlite: '3.46.0',
  tz: '2024a',
  undici: '6.13.0',
  unicode: '15.1',
  uv: '1.48.0',
  uvwasi: '0.0.20',
  v8: '12.4.254.14-node.11',
  zlib: '1.3.0.1-motley-7d77fb7' }

Exit-Codes

Node.js wird normalerweise mit einem Statuscode 0 beendet, wenn keine asynchronen Operationen mehr ausstehen. In anderen Fällen werden die folgenden Statuscodes verwendet:

1 Unbehandelte schwerwiegende Ausnahme: Es gab eine unbehandelte Ausnahme, die nicht von einer Domain oder einem 'uncaughtException'-Event-Handler behandelt wurde.
2: Unbenutzt (von Bash für den internen Missbrauch reserviert)
3 Interner JavaScript-Parse-Fehler: Der interne JavaScript-Quellcode im Node.js-Bootstrapping-Prozess verursachte einen Parse-Fehler. Dies ist äußerst selten und tritt in der Regel nur während der Entwicklung von Node.js selbst auf.
4 Interner JavaScript-Evaluierungsfehler: Der interne JavaScript-Quellcode im Node.js-Bootstrapping-Prozess konnte bei der Auswertung keinen Funktionswert zurückgeben. Dies ist äußerst selten und tritt in der Regel nur während der Entwicklung von Node.js selbst auf.
5 Schwerwiegender Fehler: Es gab einen schwerwiegenden, nicht behebaren Fehler in V8. Normalerweise wird eine Meldung mit dem Präfix FATAL ERROR an stderr ausgegeben.
6 Nicht-Funktions-Interner Ausnahme-Handler: Es gab eine unbehandelte Ausnahme, aber die interne Funktion des schwerwiegenden Ausnahmehandlers wurde irgendwie auf eine Nicht-Funktion gesetzt und konnte nicht aufgerufen werden.
7 Interner Ausnahme-Handler-Laufzeitfehler: Es gab eine unbehandelte Ausnahme, und die interne Funktion des schwerwiegenden Ausnahmehandlers warf selbst einen Fehler, als sie versuchte, ihn zu behandeln. Dies kann beispielsweise passieren, wenn ein 'uncaughtException'- oder domain.on('error')-Handler einen Fehler wirft.
8: Unbenutzt. In früheren Versionen von Node.js zeigte der Exit-Code 8 manchmal eine unbehandelte Ausnahme an.
9 Ungültiges Argument: Entweder wurde eine unbekannte Option angegeben oder eine Option, die einen Wert erfordert, wurde ohne Wert angegeben.
10 Interner JavaScript-Laufzeitfehler: Der interne JavaScript-Quellcode im Node.js-Bootstrapping-Prozess warf einen Fehler, als die Bootstrapping-Funktion aufgerufen wurde. Dies ist äußerst selten und tritt in der Regel nur während der Entwicklung von Node.js selbst auf.
12 Ungültiges Debug-Argument: Die Optionen --inspect und/oder --inspect-brk wurden gesetzt, aber die gewählte Portnummer war ungültig oder nicht verfügbar.
13 Unerfülltes Top-Level-Await: await wurde außerhalb einer Funktion im Top-Level-Code verwendet, aber das übergebene Promise wurde nie erfüllt.
14 Snapshot-Fehler: Node.js wurde gestartet, um einen V8-Start-Snapshot zu erstellen, und ist fehlgeschlagen, da bestimmte Anforderungen an den Zustand der Anwendung nicht erfüllt wurden.
\>128 Signal-Beendigungen: Wenn Node.js ein schwerwiegendes Signal wie SIGKILL oder SIGHUP empfängt, ist sein Exit-Code 128 plus der Wert des Signalcodes. Dies ist eine standardmäßige POSIX-Praxis, da Exit-Codes als 7-Bit-Integer definiert sind, und Signal-Beendigungen das High-Order-Bit setzen und dann den Wert des Signalcodes enthalten. Zum Beispiel hat das Signal SIGABRT den Wert 6, daher ist der erwartete Exit-Code 128 + 6 oder 134.

Prozess ​

Prozessereignisse ​

Ereignis: 'beforeExit' ​

Ereignis: 'disconnect' ​

Ereignis: 'exit' ​

Ereignis: 'message' ​

Ereignis: 'multipleResolves' ​

Ereignis: 'rejectionHandled' ​

Ereignis: 'workerMessage' ​

Ereignis: 'uncaughtException' ​

Warnung: 'uncaughtException' korrekt verwenden ​

Ereignis: 'uncaughtExceptionMonitor' ​

Ereignis: 'unhandledRejection' ​

Ereignis: 'warning' ​

Benutzerdefinierte Warnungen ausgeben ​

Node.js-Warnungsnamen ​

Ereignis: 'worker' ​

Signalereignisse ​

process.abort() ​

process.allowedNodeEnvironmentFlags ​

process.arch ​

process.argv ​

process.argv0 ​

process.channel ​

process.channel.ref() ​

process.channel.unref() ​

process.chdir(directory) ​

process.config ​

process.connected ​

process.constrainedMemory() ​

process.availableMemory() ​

process.cpuUsage([previousValue]) ​

process.cwd() ​

process.debugPort ​

process.disconnect() ​

process.dlopen(module, filename[, flags]) ​

process.emitWarning(warning[, options]) ​

process.emitWarning(warning[, type[, code]][, ctor]) ​

Doppelte Warnungen vermeiden ​

process.env ​

process.execArgv ​

process.execPath ​

process.exit([code]) ​

process.exitCode ​

process.features.cached_builtins ​

process.features.debug ​

process.features.inspector ​

process.features.ipv6 ​

process.features.require_module ​

process.features.tls ​

process.features.tls_alpn ​

process.features.tls_ocsp ​

process.features.tls_sni ​

process.features.typescript ​

process.features.uv ​

process.finalization.register(ref, callback) ​

process.finalization.registerBeforeExit(ref, callback) ​

process.finalization.unregister(ref) ​

process.getActiveResourcesInfo() ​

process.getBuiltinModule(id) ​

process.getegid() ​

process.geteuid() ​

process.getgid() ​

process.getgroups() ​

process.getuid() ​

process.hasUncaughtExceptionCaptureCallback() ​

process.hrtime([time]) ​

process.hrtime.bigint() ​

process.initgroups(user, extraGroup) ​

process.kill(pid[, signal]) ​

process.loadEnvFile(path) ​

process.mainModule ​

process.memoryUsage() ​

process.memoryUsage.rss() ​

process.nextTick(callback[, ...args]) ​

Wann queueMicrotask() vs. process.nextTick() verwenden ​

process.noDeprecation ​

process.permission ​

process.permission.has(scope[, reference]) ​

process.pid ​

Prozess

Prozessereignisse

Ereignis: `'beforeExit'`

Ereignis: `'disconnect'`

Ereignis: `'exit'`

Ereignis: `'message'`

Ereignis: `'multipleResolves'`

Ereignis: `'rejectionHandled'`

Ereignis: `'workerMessage'`

Ereignis: `'uncaughtException'`

Warnung: `'uncaughtException'` korrekt verwenden

Ereignis: `'uncaughtExceptionMonitor'`

Ereignis: `'unhandledRejection'`

Ereignis: `'warning'`

Benutzerdefinierte Warnungen ausgeben

Node.js-Warnungsnamen

Ereignis: `'worker'`

Signalereignisse

`process.abort()`

`process.allowedNodeEnvironmentFlags`

`process.arch`

`process.argv`

`process.argv0`

`process.channel`

`process.channel.ref()`

`process.channel.unref()`

`process.chdir(directory)`

`process.config`

`process.connected`

`process.constrainedMemory()`

`process.availableMemory()`

`process.cpuUsage([previousValue])`

`process.cwd()`

`process.debugPort`

`process.disconnect()`

`process.dlopen(module, filename[, flags])`

`process.emitWarning(warning[, options])`

`process.emitWarning(warning[, type[, code]][, ctor])`

Doppelte Warnungen vermeiden

`process.env`

`process.execArgv`

`process.execPath`

`process.exit([code])`

`process.exitCode`

`process.features.cached_builtins`

`process.features.debug`

`process.features.inspector`

`process.features.ipv6`

`process.features.require_module`

`process.features.tls`

`process.features.tls_alpn`

`process.features.tls_ocsp`

`process.features.tls_sni`

`process.features.typescript`

`process.features.uv`

`process.finalization.register(ref, callback)`

`process.finalization.registerBeforeExit(ref, callback)`

`process.finalization.unregister(ref)`

`process.getActiveResourcesInfo()`

`process.getBuiltinModule(id)`

`process.getegid()`

`process.geteuid()`

`process.getgid()`

`process.getgroups()`

`process.getuid()`

`process.hasUncaughtExceptionCaptureCallback()`

`process.hrtime([time])`

`process.hrtime.bigint()`

`process.initgroups(user, extraGroup)`

`process.kill(pid[, signal])`

`process.loadEnvFile(path)`

`process.mainModule`

`process.memoryUsage()`

`process.memoryUsage.rss()`

`process.nextTick(callback[, ...args])`

Wann `queueMicrotask()` vs. `process.nextTick()` verwenden

`process.noDeprecation`

`process.permission`

`process.permission.has(scope[, reference])`

`process.pid`