两年磨一剑：Encore如何用6.7万行Rust重写TypeScript运行时，性能提升10倍的深度技术解析

前言：当Go框架决定拥抱Rust

2026年4月，一个消息在技术社区引发了广泛讨论：Encore团队宣布其TypeScript运行时已全面重写为Rust版本——耗时两年，代码量达6.7万行，全部从零构建。

Encore最初是一个用Go语言开发的backend框架，从CLI工具到编译器再到运行时，全部用Go实现。当团队决定增加TypeScript支持时，最直觉的选择是：用TypeScript写TypeScript的运行时，或者把Go运行时改造成Sidecar模式与Node.js协同工作。

然而，他们既没有选前者，也没有选后者。

他们选了第三条路——用Rust从零重写整个TypeScript运行时。

这听起来像是一次技术上的"过度设计"，但当你深入了解他们的决策过程和技术细节后会发现，这是一个基于性能、架构和长期规划的深思熟虑的选择。

本文将深入解析Encore的Rust重写决策、Rust/Node.js的互操作架构、Tokio多线程模型的性能优势、所有权系统在请求隔离中的应用，以及整个项目中那些"事后才明白"的教训。

一、为什么不用Go Sidecar：IPC开销的代价

1.1 Sidecar方案的原型验证

Encore团队最初考虑的最简单方案，是将Go运行时作为Sidecar进程与Node.js并行运行，通过IPC（进程间通信）进行通信。TypeScript代码调用基础设施功能 → IPC传递给Go Sidecar → Go处理数据库查询/Pub/Sub/追踪 → 结果返回Node.js → 响应返回客户端。

这个设计在概念上很优雅：Go处理所有基础设施逻辑，Node.js只负责业务代码，职责清晰。

但实际测试揭示了残酷的现实。

1.2 实测：2-4ms的IPC开销是什么概念

团队对Sidecar方案进行了详细的基准测试。测试场景：一个典型的API请求，需要访问数据库（写入操作）并发布一条Pub/Sub消息。

在这个场景中，请求需要穿越IPC边界6-7次：

• 数据库连接池获取（IPC #1）
• SQL查询执行（IPC #2）
• 事务提交（IPC #3）
• Pub/Sub消息发布（IPC #4）
• 追踪事件上报（IPC #5）
• 响应序列化（IPC #6）

每穿越一次IPC边界，都涉及：数据序列化（Protobuf/JSON）→ 进程上下文切换 → 内核态转换 → 数据反序列化 → 结果同理返回。

实测结果：每个请求额外增加2-4ms的延迟。

这2-4ms听起来不多，但让我们量化一下影响：

• 假设一个电商系统的典型API（P99延迟目标：50ms），2-4ms的额外开销占用了4%-8%的延迟预算
• 如果该API需要访问两个数据库表+发布一条消息，实际IPC穿越次数会超过10次，开销会上升到5-8ms
• 高并发场景下，IPC序列化和上下文切换还会造成额外的CPU开销，形成雪崩效应

更关键的是，Sidecar方案的延迟是"无论业务逻辑多简单都存在"的固定开销。对于一个只需要读写Redis缓存的轻量API，2ms的IPC开销可能超过实际业务逻辑的耗时——这是完全无法接受的。

1.3 运维复杂度：两个进程的失败模式

除了性能问题，Sidecar方案还带来了显著的运维复杂度：

监控复杂度：两个独立进程意味着两个独立的监控指标体系、两个日志输出流、两套告警规则。在本地开发环境这是可以接受的，但当系统扩展到数十个微服务时，故障排查需要跨进程关联日志和时间线，问题定位的难度指数级上升。

故障域扩展：一个进程崩溃不会自动导致另一个崩溃，这听起来像好事，但实际上增加了系统的不确定性。当Node.js进程正常但Go Sidecar崩溃时，业务代码可能部分可用但所有基础设施调用失败，用户会看到奇怪的行为——部分请求正常，部分请求超时。这种"部分降级"比"整体失败"更难诊断和处理。

部署复杂度：需要在容器编排层面同时管理两个进程的启动顺序、健康检查和资源限制。Sidecar方案的部署配置比单进程方案复杂3-5倍。

结论：Sidecar方案的核心问题不是"不可行"，而是"不值得"。它把本应是框架提供者的基础设施逻辑变成了需要开发者额外管理的运维负担。

二、napi-rs方案：让Rust和Node.js共处一室

2.1 为什么必须是Rust而不是C++

明确了运行时必须与Node.js运行在同一个进程后，下一个选择是：用什么语言实现？

最直接的选择是用C/C++配合Node.js N-API绑定。这可以获得最高的性能，但代价是放弃了内存安全——C++中的空指针解引用、缓冲区溢出、数据竞争这些问题在Rust中可以被编译期完全消除。

Encore团队在Go运行时中已经积累了内存安全的经验，不愿意在TypeScript运行时中重新引入这类风险。

Rust提供了另一个关键优势：Tokio异步生态。Node.js本身是单线程的事件循环模型，所有I/O操作都是非阻塞的，但Node.js无法原生利用多核CPU。通过在Rust中实现运行时，可以将所有基础设施I/O操作（HTTP路由、数据库连接、Pub/Sub、追踪）放在Tokio的多线程执行器中执行，充分利用多核CPU的并发能力。

2.2 N-API的两种调用方向

Node.js N-API（也称N-API）是Node.js官方提供的原生模块接口，设计初衷是从JavaScript调用原生代码：

// JavaScript调用原生模块
const myAddon = require('./my_addon.node');
myAddon.processData(data); // 调用Rust/C++实现的函数

N-API为这种场景提供了完善的API：注册原生函数 → JavaScript传入参数 → 原生代码执行 → 返回值回JavaScript。这个方向的工作流程非常顺畅。

但Encore需要的恰好是反方向：从Rust调用JavaScript。

这是一个完全不同的挑战。当一个Pub/Sub消息到达时，Rust运行时需要将消息分发给对应的TypeScript处理器函数；当一个HTTP请求到达时，Rust需要调用相应的TypeScript端点函数。这些"从Rust调用JavaScript"的场景，N-API的设计初衷并未覆盖。

2.3 ThreadSafeFunction的魔改：捕获JavaScript返回值

napi-rs提供了ThreadSafeFunction，允许从Rust线程安全地调用JavaScript函数。但标准实现只支持"发送参数，不关心返回值"的使用模式——这对于 Encore的场景是远远不够的。

Encore需要知道TypeScript handler的返回值：API端点返回了什么响应？Pub/Sub handler成功还是失败？

团队Fork了napi-rs的ThreadSafeFunction，改造了调用机制：

// Encore改造的ThreadSafeCallContext
// 关键改进：从Rust侧手动调用JS函数并捕获返回值

pub struct ThreadSafeCallContext<T: 'static> {
    pub env: Env,                    // N-API环境句柄
    pub value: T,                    // 要传递给JS函数的参数
    pub callback: Option<JsFunction>, // 可选的回调函数
}

// 核心调用逻辑
fn call_js_and_capture_return(env: &Env, js_function: JsFunction, arg: JsValue) -> Result<JsValue> {
    // 调用JS函数
    let result = js_function.call(None, &[arg])?;
    
    // 检查是否是Promise
    if result.is_promise()? {
        // 链入.then()回调，将结果通过tokio channel送回Rust侧
        let (tx, rx) = tokio::sync::oneshot::channel();
        let promise_chain = result.await_promise(rx)?;
        return Ok(promise_chain);
    }
    
    // 同步返回值，直接返回
    Ok(result)
}

这个改造的核心是：把JavaScript的Promise模型桥接到Rust的异步执行模型。当一个async handler返回一个Promise时，Rust通过Tokio channel等待Promise resolve，然后捕获最终结果用于后续处理（如序列化HTTP响应）。

2.4 两种生命周期的融合

Encore的Rust/Node.js架构不是传统的主/客（host/guest）模式，而是一种"共生"架构：

┌─────────────────────────────────────────────┐
│                  进程（Process）              │
│  ┌──────────────────────────────────────┐   │
│  │         Node.js/Bun 事件循环          │   │
│  │  (进程生命周期管理，JS引擎，V8/Bun JSC) │   │
│  └──────────────────────────────────────┘   │
│                  ↑ 调用                     │
│  ┌──────────────────────────────────────┐   │
│  │         Encore Rust 运行时            │   │
│  │  (HTTP路由, 数据库连接, Pub/Sub,       │   │
│  │   追踪, 指标, 对象存储, 缓存)           │   │
│  │  (Tokio多线程异步执行器)               │   │
│  └──────────────────────────────────────┘   │
│                                             │
│  TypeScript代码 = 纯业务逻辑（无基础设施代码）│
└─────────────────────────────────────────────┘

Node.js/Bun负责启动进程并导入Encore原生库。原生库接管所有基础设施层——HTTP请求的路由和分发、数据库连接池的管理、Pub/Sub消息的分发、分布式追踪的采集。业务代码（TypeScript写的API handlers、Pub/Sub subscribers）只需要专注于业务逻辑。

这是一个根本性的范式转移：TypeScript开发者不再需要关心"如何连接数据库"，只需要声明"这个函数需要访问哪个数据库"，基础设施由Rust运行时自动处理。

三、核心架构：6.7万行Rust的模块化设计

3.1 Manager模式：每个基础设施一个管理器

Encore的Rust核心运行时采用了一种清晰到极致的模块化设计——Manager模式：

// 运行时核心结构：每个基础设施功能对应一个Manager
pub struct Runtime {
    // HTTP请求生命周期：路由、请求解析、认证、响应序列化
    api: api::Manager,
    
    // 数据库：连接池管理、查询执行、事务处理
    sqldb: sqldb::Manager,
    
    // 消息队列：主题发布和订阅处理
    pubsub: pubsub::Manager,
    
    // 对象存储：S3/GCS等云存储的集成
    objects: objects::Manager,
    
    // 指标收集：Prometheus/OTLP格式的指标导出
    metrics: metrics::Manager,
    
    // 密钥管理：运行时密钥获取和缓存
    secrets: secrets::Manager,
    
    // ... 更多的Manager
}

每个Manager都是完全独立的，负责一个明确的基础设施功能。这种设计有几个关键优势：

独立演进：可以单独升级或重写某个Manager而不影响其他部分。例如，当AWS发布新版本的SDK时，只需要更新pubsub::Manager中的AWS实现层，不需要触碰HTTP路由或数据库连接池。

易于测试：每个Manager可以独立进行单元测试和集成测试，使用mock实现隔离依赖。

清晰的所有权：当某个功能出现问题时，错误定位非常直接——数据库连接问题找sqldb::Manager，消息队列问题找pubsub::Manager。

3.2 双Protobuf配置：编译时元数据 + 运行时配置

这是Encore架构中最精妙的设计——双Protobuf配置分离：

第一层：应用元数据（编译时生成）

// 应用元数据 —— 在编译时由TypeScript解析器生成
// 描述整个应用系统的完整结构，不包含环境信息
message Data {
    string module_path = 1;              // 模块路径
    repeated Service svcs = 5;           // 所有服务定义
    optional AuthHandler auth_handler = 6; // 认证处理器
    repeated CronJob cron_jobs = 7;      // 定时任务
    repeated PubSubTopic pubsub_topics = 9; // Pub/Sub主题
    repeated CacheCluster cache_clusters = 11; // 缓存集群
    repeated SQLDatabase sql_databases = 14;   // SQL数据库
    repeated Gateway gateways = 15;      // API网关
    repeated Bucket buckets = 17;        // 对象存储桶
    // ... 更多字段
}

TypeScript解析器在编译时读取你的应用代码，提取所有基础设施声明（@数据库、@订阅、@API等装饰器），生成这份元数据Protobuf文件。

第二层：运行时配置（部署时生成）

// 运行时配置 —— 在部署时根据目标环境生成
// 描述如何运行：云厂商、认证方式、服务发现配置等
message RuntimeConfig {
    Environment environment = 1;   // 云厂商和环境类型（dev/prod/test）
    Infrastructure infra = 2;     // SQL集群、Pub/Sub、Redis、密钥、存储桶
    Deployment deployment = 3;    // 服务发现、认证方法、可观测性配置
}

这个配置在Encore Cloud部署时自动生成，包含生产环境的具体连接信息（数据库地址、AWS区域、认证密钥等）。

为什么这个分离至关重要？

它实现了"同一套代码，多环境运行"的能力。同一个应用可以：

• 本地开发时：使用Docker Compose的本地PostgreSQL + NSQ消息队列
• 测试环境：使用云厂商的测试集群
• 生产环境：使用AWS RDS + SNS/SQS

应用代码本身不需要修改，部署时只需替换运行时配置Protobuf。这解决了微服务架构中最常见的"环境差异导致本地正常但生产出错"问题。

3.3 Pingora驱动的API网关

Encore的HTTP入口也值得关注——他们采用了Cloudflare开源的Pingora作为API网关核心。

Pingora是Cloudflare用Rust重写Nginx的成果，替换了原来用C++写的代理服务器。使用Pingora而非直接用Rust实现HTTP服务器的原因：

• Cloudflare已在大规模生产环境中验证了Pingora的可靠性和性能
• HTTP/2、WebSocket、TLS等复杂协议的实现需要大量维护工作，Pingora已完整实现
• Cloudflare每年处理数十亿HTTP请求，Pingora的性能和安全性都经过了严苛验证

四、Tokio多线程：Node.js单线程的破局之道

4.1 Node.js的核心限制：单线程事件循环

Node.js（以及Bun）的核心架构是一个单线程事件循环。所有JavaScript代码都在主线程执行，I/O操作通过libuv的线程池异步处理，但实际的业务逻辑永远是单线程的。

这个设计在2009年是一个精妙的折中——JavaScript的天生异步性（回调函数）恰好适合I/O密集型场景，单线程避免了锁竞争，事件循环模型简化了并发编程。

但2026年的后端服务场景完全不同：

• 现代服务器的CPU核心数从8核到128核不等，Node.js只能利用其中1核
• 数据库连接池、HTTP请求、文件I/O——这些I/O操作完成后需要在主线程回调，大量回调争抢同一CPU核心
• 对于CPU密集型的数据处理（JSON序列化、响应压缩、加密），Node.js的性能远不如多线程方案

4.2 Tokio的全异步执行器：所有I/O并行处理

当Encore将基础设施逻辑移入Rust后，情况发生了根本性改变：

// 典型的Encore HTTP handler处理流程（Rust侧）
async fn handle_api_request(req: Request) -> Result<Response> {
    // 三个I/O操作并行发起
    let (db_result, pubsub_result, tracing_result) = tokio::join!(
        // 数据库查询（连接池中获取连接 → 执行查询 → 返回结果）
        sql_db.query(&req.path_params),
        // Pub/Sub消息发布
        pubsub.publish("user_action", payload),
        // 追踪span创建
        tracing.record_request(&req)
    );
    
    // 三个操作同时在Tokio的不同线程上执行
    // Node.js主线程只收到最终的聚合结果
    
    Ok(Response::new(db_result))
}

tokio::join!宏会同时发起三个异步任务，它们分别在Tokio工作线程池中的不同线程上执行。数据库查询正在等待网络响应时，Pub/Sub消息已经发布，追踪已经记录——这三个I/O操作完全没有相互阻塞。

在Node.js的单线程模型下，实现同样的并行需要非常复杂的Promise.all组合，且所有回调都在主线程执行，高并发时会遇到主线程瓶颈。在Rust/Tokio模型中，这只是一个简单的tokio::join!调用。

4.3 分层队列架构：负载均衡的艺术

Tokio的运行时采用了精心设计的分层队列架构：

// Tokio运行时配置：分层队列 + 工作窃取
fn create_optimized_runtime() -> Runtime {
    Builder::new_multi_thread()
        .worker_threads(num_cpus::get()) // 工作线程数 = CPU核心数
        .thread_name("encore-worker")
        .enable_all() // 启用所有I/O驱动（TCP/UDP/文件/timer）
        
        // 全局队列检查间隔（质数，减少碰撞）
        .global_queue_interval(31)
        
        // 事件循环检查间隔
        .event_interval(61)
        
        // 线程栈大小（2MB，适合异步任务）
        .thread_stack_size(2 * 1024 * 1024)
        
        .enable_time()
        .build()
        .expect("Failed to create runtime")
}

本地LIFO队列 + 全局FIFO注入队列 + 工作窃取：

• 每个工作线程有一个本地LIFO（后进先出）队列：新任务优先放入当前线程队列，利用CPU缓存局部性优化
• 共享一个全局FIFO注入队列：外部任务（来自JavaScript的调用）进入全局队列
• 工作窃取机制：当某个工作线程的本地队列为空时，它会从其他线程的本地队列"窃取"任务，保持负载均衡

这种设计确保了即使在混合负载（短任务+长任务+I/O密集+CPU密集）下，Tokio也能高效地分配任务到所有CPU核心。

4.4 所有权系统：请求间资源隔离的零成本保证

Rust的所有权系统为Encore带来了一个额外的架构优势——请求间的自动资源隔离，不需要任何额外的运行时成本。

在Node.js的单线程模型中，所有请求共享同一个堆内存。如果某个请求泄漏了大量对象，只有在GC触发时才会清理，可能影响其他请求。

在Rust中，每个请求的状态可以通过生命周期（'request）进行严格隔离：

// 请求级资源管理：生命周期绑定确保资源在请求结束时自动释放
async fn handle_request<'req>(
    req: Request<'req>,
    db_pool: &DbPool,
) -> Result<Response> {
    // db_conn 的生命周期被 'req 约束
    // 当 handle_request 返回时，db_conn 必然已返还连接池
    // 编译期保证，零运行时开销
    
    let db_conn = db_pool.acquire().await?; // 获取连接
    let result = db_conn.query(&req.sql).await?;
    
    // 无论成功还是出错，'req 生命周期结束时：
    // - db_conn 自动返还连接池
    // - 任何请求级堆分配自动释放
    // - 没有任何东西可以被"遗忘"
    
    Ok(Response::new(result))
}

编译期保证意味着：开发者不可能写出"忘记释放连接"的代码，连接泄漏在编译阶段就被杜绝了。这种保证在Node.js/TypeScript中需要依赖lint规则、代码审查和运行时监控来规避，在Rust中只是一个编译成功就自动获得的免费保证。

五、异步死锁的规避：从教训中学到的工程实践

5.1 Tokio中的异步死锁：不是显而易见的问题

Encore团队在两年的开发中遇到了一个最初没有预料到的挑战：异步死锁。

传统的死锁（两个线程互相等待对方持有的锁）对于有经验的开发者来说是比较直观的——用lock ordering、层级锁或细粒度锁策略都可以规避。

但异步上下文中的死锁要微妙得多。在Tokio的多线程执行器中，如果一个async任务持有.await点，同时其他任务在等待它释放某个资源，而该资源的状态又取决于.await点的结果——死锁就发生了。

一个典型的人间迷惑案例：

// 危险代码：Tokio中的潜在死锁
async fn process_batch(items: Vec<Item>) -> Result<Vec<Result>> {
    let mut results = Vec::new();
    
    for item in items {
        // 问题：逐个等待。每个item的处理都阻塞下一个。
        // 在高并发场景下，如果某个item的处理卡住，
        // 整个batch永远无法完成
        let result = process_item(&item).await;
        results.push(result);
    }
    
    Ok(results)
}

// 更安全的并发处理
async fn process_batch_safe(items: Vec<Item>) -> Result<Vec<Result>> {
    let futures: Vec<_> = items.iter()
        .map(|item| process_item(item))
        .collect();
    
    // 并发执行所有任务，超时控制防止永远挂起
    let results = tokio::time::timeout(
        Duration::from_secs(30),
        futures::future::join_all(futures)
    ).await??;
    
    Ok(results)
}

5.2 Rust所有权系统如何帮助检测死锁

虽然Rust的所有权系统不能自动检测异步死锁，但它通过类型系统强制开发者明确"哪个资源在哪个作用域内"——这种显式性间接减少了死锁的发生概率：

• Arc<Mutex<T>> 明确表示"这是一个需要同步访问的共享状态"
• tokio::sync::Mutex（异步互斥锁）要求await来获取，不像std::sync::Mutex可以跨.await点持有
• Send + Sync约束确保跨线程的数据流被正确追踪

但Encore团队仍然建议：对于复杂的异步工作流，在设计阶段就绘制状态图，识别循环依赖。

六、与现有方案的对比：Encore的独特位置

6.1 Encore vs 传统Node.js后端框架

6.2 Encore vs Go运行时

Encore同时提供Go和TypeScript两种运行时。Go运行时继续维护并正常工作，两者的差异在于：

有趣的是，Rust运行时的性能略优于Go运行时——主要得益于Rust的所有权系统允许更高效的内存布局和更少的运行时开销（Go有GC，Rust没有）。

七、实战：从迁移到生产：Encore开发者的体验

7.1 TypeScript开发者的视角

对于TypeScript开发者来说，Encore的Rust运行时是完全透明的。你写的是纯TypeScript代码，基础设施的复杂性被隐藏在框架层：

// Encore TypeScript开发者写的代码 —— 纯业务逻辑
import { api, db, pubsub } from "encore.dev/api";
import { sql } from "encore.dev/storage/db";

// 声明式数据库表定义
const myDB = new sql.Database("mydb");

// 声明式API端点
export const getUser = api(
  { method: "GET", path: "/users/:id", auth: false },
  async (req: { id: string }): Promise<User> => {
    // 简单的SQL查询 —— 基础设施自动处理连接池
    const row = await myDB.query`
      SELECT id, name, email FROM users WHERE id = ${req.id}
    `;
    
    if (!row.rows[0]) {
      throw new Error("User not found");
    }
    
    return row.rows[0] as User;
  }
);

// 声明式Pub/Sub
export const notifyNewUser = pubsub.topic(
  "user.created",
  { deliveryPolicy: "atLeastOnce" }
);

// 在handler中发布事件
export const createUser = api(
  { method: "POST", path: "/users", auth: true },
  async (req: CreateUserRequest): Promise<User> => {
    // 创建用户到数据库...
    const user = { id: uuid(), name: req.name, email: req.email };
    
    // 发布事件 —— 连接管理和消息序列化自动处理
    await notifyNewUser.publish({ userId: user.id, email: user.email });
    
    return user;
  }
);

这就是Encore的核心价值：你声明意图，框架处理所有实现细节。不需要关心连接池大小、不需要手动管理Pub/Sub客户端、不需要编写追踪span。

7.2 迁移成本：从现有Node.js项目迁移

对于已有Express或Fastify项目的团队，迁移到Encore的成本取决于项目规模：

低复杂度迁移场景（个人项目、小团队）：

• 替换Express Router → Encore API声明
• 替换pg客户端 → Encore SQL Database
• 替换@google-cloud/pubsub → Encore PubSub
• 迁移成本：1-2周

高复杂度迁移场景（大型生产系统）：

• 需要重写所有基础设施调用
• 需要重新设计类型系统（Encore的声明式API有严格的类型约束）
• 需要为每个环境生成不同的运行时配置
• 迁移成本：1-3个月

不过，Encore也支持与现有Node.js服务共存——你可以将新功能用Encore实现，同时保留现有服务，逐步迁移。

八、架构的局限性与边界场景

8.1 异步取消的边界问题

Encore团队在开发过程中遇到了一个有趣的技术挑战：Rust的Future可以被随时丢弃（当请求超时或连接关闭时），但JavaScript handler仍在Node.js事件循环上运行，无法被取消。

// 边缘场景：Rust Future被丢弃，但JS Handler仍在运行
// Cloud Run请求超时 → 连接关闭 → Rust侧Future被drop
// 但此时Node.js事件循环上的TypeScript handler正在执行...
// 需要某种机制告知JS端"停止处理"

这个问题没有完美的解决方案。Encore选择接受这个限制：在极端情况下（请求超时），正在处理的JavaScript handler可能会继续运行一小段时间，直到它完成或发现连接已关闭。

8.2 不适合的场景

Encore的Rust运行时架构并不适合所有场景：

• 超轻量函数：对于只需要几行简单逻辑的API，Encore的声明式开销可能超过收益
• 需要Node.js原生模块的场景：如果项目大量依赖Node.js原生addon，Rust运行时可能产生冲突
• 边缘计算环境：内存极度受限的环境下，Rust运行时的内存占用（约50-100MB）可能比Node.js（约30-50MB）更高

结语：Rust在后端框架领域的又一次验证

Encore的Rust重写不是技术炫技，而是一次基于数据驱动的架构决策。Sidecar方案的IPC开销实测数据、Node.js单线程的性能瓶颈、Go运行时的并发模型局限性——这些具体的数字和约束，驱动团队走向了Rust。

6.7万行Rust代码背后，是一个值得深思的工程哲学：当你为一个技术选型寻找论据时，不要只听信"这是一种好语言"的说法，而是要问——它解决了我真正面临的问题吗？

对于Encore来说，Rust解决了三个真正的问题：内存安全（避免C++的风险）、多核利用（绕过Node.js的限制）、跨语言扩展（Rust核心绑定多语言运行时）。

两年时间，67,000行代码，零运行时GC——这是一次关于"用什么工具做什么事"的诚实回答。

标签：Rust,TypeScript,Encore,Tokio,Node.js,后端框架,N-API,性能优化,异步编程,运行时,多线程

关键词：Encore Rust TypeScript运行时,Rust重写Node.js运行时,Tokio多线程性能,napi-rs互操作,Rust所有权系统请求隔离,Encore架构解析,后端框架Rust化,异步死锁规避,TypeScript声明式API,全栈性能优化