如何使用 try-catch 全量拦截并审计跨端桌面应用中原生底层进程的异步核心抛错行为规范

不能用 try-catch 全量拦截原生底层进程的异步抛错行为，因其无法跨进程、跨线程、跨语言捕获；需通过进程监控、标准流审计、IPC 错误封装、崩溃快照等分层机制实现全量可观测与审计。

不能用 try-catch 全量拦截原生底层进程的异步抛错行为。

try-catch 本身不具备跨进程、跨线程、跨语言捕获能力

桌面应用中调用的原生底层进程（如通过 Node.js 的 child_process 启动的独立可执行文件、C++ 插件、Rust 二进制模块、或系统级服务）属于独立操作系统进程，其异常发生在不同地址空间、不同运行时环境，甚至不同语言栈中。JavaScript/TypeScript 的 try-catch 仅作用于当前 JS 执行上下文中的同步或 await 等待的 Promise 异常，对以下情况完全无效：

• 子进程 stdout/stderr 输出错误但未显式 reject（例如 Python 脚本打印 traceback 后退出，但主进程未监听 error 或 exit）
• 子进程因段错误（SIGSEGV）、被 kill（SIGKILL）、超时强制终止等导致的非正常退出
• C++ 插件中未通过 NAPI/Node-API 抛出 JS 异常，而是直接崩溃或写日志
• Rust FFI 返回的是 Result<T, E>，但 JS 层未做 unwrap() 或错误映射，就默认当作成功处理

真正可行的“全量拦截与审计”需分层建设

所谓“全量”，不是靠语法糖兜底，而是建立覆盖进程生命周期、通信通道、错误语义的可观测链路：

• 进程启动与存活监控：监听 spawn 后的 error 事件（启动失败）、exit 事件（退出码 + signal）、close 事件（流关闭），记录 timestamp、pid、exitCode、signal、启动参数
• 标准流内容审计：对 stderr 做实时文本匹配（如关键词 “panic:”, “Exception:”, “Segmentation fault”, “FATAL”），触发告警并截取上下文行；对 stdout 中约定的 JSON 错误格式（如 {"level":"error","msg":"..."}）做结构化解析
• IPC 协议级错误封装：所有 JS ↔ 原生模块的通信必须定义明确的错误响应结构（如 { success: false, code: 'PROCESS_CRASH', detail: { pid: 1234, signal: 'SIGABRT' } }），禁止裸传字符串或静默丢弃
• 崩溃现场快照：在子进程启动前注入环境变量（如 CRASH_DUMP_DIR=/tmp/myapp-crash），配合原生层生成 core dump / minidump，并由主进程定期扫描上报

async/await + try-catch 仅适用于“可控桥接层”

它只能保护你写的那一小段 JS 胶水代码，前提是：原生调用已被封装为返回 Promise 的函数，且该 Promise 在底层出错时正确 reject。示例：

✅ 正确封装（暴露可捕获的 Promise）

async function runNativeTool(args) {  return new Promise((resolve, reject) => {    const proc = spawn('mytool', args);    proc.on('error', reject); // 启动失败    proc.on('exit', (code, signal) => {      if (code !== 0 || signal) {        reject(new Error(`Tool exited with code ${code}, signal ${signal}`));      } else {        resolve();      }    });    proc.stderr.on('data', (chunk) => {      const str = chunk.toString();      if (/panic|FATAL/i.test(str)) {        reject(new Error(`Native tool panic: ${str.slice(0, 200)}`));      }    });  });}// 此处 try-catch 才真正有效try {  await runNativeTool(['--validate', '/path']);} catch (e) {  auditLog.error('Native tool failed', { error: e.message, traceId: currentTraceId });}

审计不是捕获，而是统一归因与可追溯

最终审计目标不是“不让错发生”，而是确保每个底层错误都能关联到：

• 触发该操作的用户行为（如点击了哪个按钮、执行了哪条命令）
• 当时的运行上下文（OS 版本、架构、内存余量、磁盘空间）
• 完整的调用链（JS → IPC → 原生入口 → 子进程启动 → stderr 流）
• 错误分类标签（crash / timeout / validation-fail / oom / permission-denied）

这需要在各层主动注入 traceId、打点日志、结构化错误对象，而非依赖某一行 try-catch。