Node.js N-API 和原生扩展适合解决什么问题？

简化版

N-API 是 Node.js 提供的稳定 C ABI，用来编写跨 Node 版本更稳定的原生扩展。原生扩展适合 CPU 密集、复用 C/C++ 库、系统能力封装等场景，但会增加构建、发布、跨平台和崩溃风险。

Node.js 主要运行 JavaScript，但有时需要调用 C/C++ 能力。例如图片处理、加密压缩、数据库驱动、硬件接口或复用已有 native SDK。 N-API 提供相对稳定的接口，让扩展不必直接依赖 V8 内部 API。

JavaScript
-> Node Addon
-> N-API
-> C/C++ library

面试要讲清楚：原生扩展不是普通性能优化首选。优先考虑算法优化、Worker Threads、WASM 或成熟库；只有确实需要 native 能力时再引入。

JavaScript 适合 I/O 和业务编排，但某些场景天然需要底层能力。例如高性能图像编解码、加密算法、音视频处理、硬件设备 SDK、数据库底层驱动。这些能力可能已经有成熟 C/C++ 库，重写成 JS 成本很高。

业务 JS
-> 调用 addon 方法 resizeImage()
-> native 层调用 libvips
-> 返回处理结果

如果一个图片压缩任务 JS 实现需要 800ms，native 库只要 80ms，并且调用频繁，原生扩展就有价值。但这个收益要和复杂度一起评估。

早期原生扩展经常直接依赖 V8 和 Node 内部 API。 Node 或 V8 升级后，扩展可能需要重新适配。 N-API 的目标是提供稳定 ABI，降低跨 Node 版本维护成本。

直接 V8 API:
Addon -> V8 内部接口 -> 版本变化风险高

N-API:
Addon -> 稳定 ABI -> Node/V8 变化影响更小

这里的重点不是背 API 名字。而是知道 N-API 解决的是 native addon 的版本稳定问题。

JS 包通常跨平台运行。原生扩展要面对 Windows、macOS、Linux、x64、arm64、glibc、musl 等差异。用户安装时可能需要编译工具链，也可能下载预编译二进制。

发布矩阵:
darwin-x64
darwin-arm64
linux-x64-gnu
linux-x64-musl
win32-x64

如果一个团队没有维护二进制产物的经验，引入 addon 会让 CI/CD 和用户安装复杂很多。这也是很多库提供 prebuild 的原因。

JavaScript 抛异常通常可以捕获。 C/C++ 层如果出现段错误、非法内存访问，可能直接让进程崩溃。这类问题比普通 JS bug 更难排查。

JS Error:
throw -> catch -> 记录日志

Native crash:
segmentation fault -> 进程退出

如果服务进程因为 native addon 崩溃，PM2 或容器可以拉起，但正在处理的请求会失败。所以 native 扩展要更严格测试和隔离。

Node 遇到 CPU 密集任务时，第一反应不一定是写 C++。可以先优化算法、减少数据量、用 Worker Threads 隔离 CPU、用 WASM，或调用外部服务。原生扩展是成本较高的选项。

优化顺序:
算法和数据结构
缓存和批处理
Worker Threads
WASM 或成熟 native 库
自研 N-API addon

如果任务只是偶尔跑一次，native 带来的维护成本可能超过收益。如果任务是核心链路且已有成熟 C 库，封装 native 才更合理。

JS 调 native 有边界成本。如果每处理一个字节就调用一次 native，开销会很大。应该设计粗粒度接口，一次传入一块数据，让 native 层完成批量计算。

差:
for 100000 items -> call native 100000 times

好:
一次传数组 -> native 批量处理 -> 一次返回

记忆钩子：N-API 是通往 C/C++ 的桥，桥很有用，但不能把每一步都走成过桥。

面试回答要体现取舍。 native 不是万能加速器，而是有明确边界和成本的工程选项。

N-API 题按“能力和代价”记。它让 Node 能稳定调用 C/C++ 扩展，适合高性能库和底层能力封装；代价是构建发布、跨平台、崩溃风险和边界成本。优先级上，别把 native 当第一根救命稻草。