deno_runtime 运行时库剖析MainWorker、bootstrap 流程与 WebWorker 架构Deno 源码实战【免费下载链接】denoA modern runtime for JavaScript and TypeScript.项目地址: https://gitcode.com/GitHub_Trending/de/deno本文基于 Deno 仓库中的 runtime/README.md 展开系统讲解deno_runtimecrate 的定位与 API 设计如何以MainWorker封装deno_core::JsRuntime并注入Deno命名空间的 ops、如何完成bootstrap初始化、如何通过WorkerOptions/BootstrapOptions定制模块加载、错误格式化、V8 inspector、User-Agent、CA 证书与随机数种子等运行时属性以及WebWorker如何以“每 worker 一个专用 OS 线程”的模型实现 WebWorkerAPI。读完后你可以理解 Deno CLI 的运行时底座是如何搭建的并具备在自定义宿主中嵌入deno_runtime的工程思路。deno_runtime 是什么Deno CLI 的“瘦身版”README 对 crate 的定义非常明确它是 Deno CLI 的精简版本移除了 TypeScript 集成以及 lint、doc 等工具链本质上只保留JavaScript 执行能力加上 Deno 的操作系统绑定ops。这个 crate 发布在 crates.io 上包名为deno_runtime当前仓库中版本为0.266.0描述为 Provides the deno runtime library见 runtime/Cargo.toml。README 同时给出了一段重要的稳定性声明该 crate 由原先位于denocrate 中、久经考验的模块构建而成但其API 处于快速变化阶段随时可能发生破坏性变更。因此引用它的下游项目需要做好跟随升级的准备。从 runtime/Cargo.toml 的 features 定义可以看出该 crate 的几个编译开关它们对应不同的集成场景docsrs一个假 feature仅用于在 docs.rs 上正常生成文档exclude_runtime_main_js从导出的扩展中排除js/99_main.js适合宿主希望自行接管主模块引导逻辑的场景snapshot/transpile启用 V8 快照能力snapshot依赖transpile后者引入deno_asthmr开发特性禁用快照的创建与加载改为在运行时从磁盘读取各扩展的lazy_loaded_*源文件。它聚合了哪些能力deno_runtime自身并不从零实现 Web API而是把 Deno 的各个能力 crate 重新导出并组装。从 runtime/lib.rs 可以看到它pub use了二十多个功能模块pub use deno_cache; pub use deno_core; pub use deno_crypto; pub use deno_fetch; pub use deno_ffi; pub use deno_fs; pub use deno_http; pub use deno_kv; pub use deno_napi; pub use deno_net; pub use deno_node; pub use deno_os; pub use deno_permissions; pub use deno_process; pub use deno_web; pub use deno_webgpu; pub use deno_websocket; // ...并对外暴露了自身的关键模块code_cacheV8 代码缓存、coverage覆盖率、cpu_profilerCPU 剖析、fmt_errors错误格式化、js内置 JS 源、ops宿主 ops、permissions权限系统、snapshot快照feature 开关控制、web_worker、worker等。此外还重导出deno_features中的FeatureChecker与UNSTABLE_FEATURES用于--unstable-*特性门禁。换句话说README 所说的“JavaScript 执行 操作系统绑定”在这套 re-export 与扩展注册中得到了具体体现。主 APIMainWorkerREADME 指出该 crate 的主 API 是MainWorker一个封装了deno_core::JsRuntime、并带有一组用于实现Deno命名空间的 ops 的结构体。源码与文档一致见 runtime/worker.rs/// This worker is created and used by almost all /// subcommands in Deno executable. /// /// It provides ops available in the Deno namespace. /// /// All WebWorkers created during program execution /// are descendants of this worker. pub struct MainWorker { pub js_runtime: JsRuntime, should_break_on_first_statement: bool, should_wait_for_inspector_session: bool, exit_code: ExitCode, bootstrap_fn_global: Optionv8::Globalv8::Function, dispatch_load_event_fn_global: v8::Globalv8::Function, dispatch_beforeunload_event_fn_global: v8::Globalv8::Function, dispatch_unload_event_fn_global: v8::Globalv8::Function, dispatch_process_beforeexit_event_fn_global: v8::Globalv8::Function, dispatch_process_exit_event_fn_global: v8::Globalv8::Function, memory_trim_handle: Optiontokio::task::JoinHandle(), }从字段设计可以读出几个实现事实MainWorker的“人格”由两个回调集合构成bootstrap_fn_globalJS 侧 bootstrap 入口被bootstrap调用一次后消费和五个事件分发函数——load、beforeunload、unload、process:beforeExit、process:exit。这说明MainWorker承担了 Node 风格的进程级事件生命周期should_break_on_first_statement与should_wait_for_inspector_session对应--inspect调试场景等待调试器连接、在第一条语句处断点Drop实现会 abortmemory_trim_handle即 worker 销毁时终止周期性的内存整理任务。创建 MainWorkerbootstrap_from_optionsREADME 强调“创建MainWorker的实现者必须调用MainWorker::bootstrap来准备 JS runtime”。当前源码中这一约定收敛为组合方法bootstrap_from_optionsruntime/worker.rs先通过私有的from_options构造出 worker 和BootstrapOptions再立即调用worker.bootstrap(bootstrap_options)保证创建与初始化不可分离。from_options接收两个大参数正好对应 README 列举的可配置项1.WorkerServiceOptionsruntime/worker.rs——宿主必须提供的服务依赖字段作用module_loader: Rcdyn ModuleLoaderV8 请求加载 ES 模块时的回调实现不提供则执行代码尝试加载模块会直接报错对应 README 的“module loading implementation”permissions: PermissionsContainer权限容器多数 ops 依赖它做权限检查fs、blob_store、fetch_dns_resolver文件系统、Blob 存储、DNS 解析器root_cert_store_provider自定义根证书存储对应 README 的 “CA certificate” 定制shared_array_buffer_store多 isolate 间共享SharedArrayBuffer不提供则无法序列化compiled_wasm_module_store多 isolate 间共享已编译的WebAssembly.Modulev8_code_cache模块/脚本源码的 V8 代码缓存node_services/npm_process_state_provider可选的 Node 兼容与 npm 集成服务2.WorkerOptionsruntime/worker.rs——运行时行为参数字段作用bootstrap: BootstrapOptions注入 JS 环境的启动配置下一节详述extensions: VecExtension额外注册的扩展ops 与 JS/ESM 源若已用快照则不应重复提供已快照化的 JSstartup_snapshot: Optionstatic [u8]启动时加载的 V8 快照seed: Optionu64随机数生成器种子对应 README 的 “random number generator seed”unsafely_ignore_certificate_errors对指定域名忽略证书错误create_web_worker_cb创建WebWorker时必须提供的回调README 中 WebWorker 一节的硬性要求见后文format_js_error_fn: OptionArcFormatJsErrorFn错误格式化钩子对应 README 的 “error formatting”create_paramsisolate 创建参数例如堆内存上限wait_for_inspector_session类标志对应 README 的 “V8 inspector 与 Chrome DevTools 调试器支持”快照分支UnconfiguredRuntime 的两阶段构建WorkerOptions中还有一个值得注意的选项unconfigured_runtime当宿主如 IDE 语言服务或 LSP 场景需要复用已经创建好的运行时而不想重新构建时可以先通过UnconfiguredRuntime::new建立运行时runtime/worker.rs。它内部用PlaceholderModuleLoader占位——一个所有方法都先unwrap一个尚未插入的真实ModuleLoader的空壳随后hydrate(module_loader)把真实的加载器注入占位符并返回JsRuntime。from_options中检测到unconfigured_runtime后走hydrate分支而非现场构建扩展与 runtime并且一旦请求了trace_ops或 op metrics占位 runtime 会被丢弃回退到常规路径因为这两项必须在创建期配置。BootstrapOptions注入 JS 环境的“配置总线”bootstrap阶段真正发生的事是把BootstrapOptions序列化后传给 JS 侧执行99_main.js的引导逻辑。BootstrapOptions定义在 runtime/worker_bootstrap.rs其字段覆盖了 README 可配置清单中“进程级”的那一部分pub struct BootstrapOptions { pub deno_version: String, /// Sets Deno.args in JS runtime. pub args: VecString, pub cpu_count: usize, pub log_level: WorkerLogLevel, pub enable_testing_features: bool, pub locale: String, pub location: OptionModuleSpecifier, pub color_level: deno_terminal::colors::ColorLevel, // --unstable-* flags pub unstable_features: Veci32, pub user_agent: String, pub inspect: bool, /// If this is a deno compile-ed executable. pub is_standalone: bool, pub has_node_modules_dir: bool, pub argv0: OptionString, pub node_debug: OptionString, pub mode: WorkerExecutionMode, // Used by deno serve pub serve_port: Optionu16, pub serve_host: OptionString, pub auto_serve: bool, pub otel_config: OtelConfig, pub close_on_idle: bool, pub disable_offscreen_canvas: bool, }其中几个字段与 README 的可配置项直接对应user_agent“HTTP client user agent”定制、inspectinspector 支持、unstable_features细粒度 unstable 特性位。Default实现worker_bootstrap.rs透露了合理默认值的来源cpu_count取thread::available_parallelism()user_agent格式为Deno/{CARGO_PKG_VERSION}locale默认enmode默认WorkerExecutionMode::None。注释还特意提醒默认 user_agent 用的是 crate 版本号实现者应当提供更有意义的 UA。序列化路径也值得细看as_v8通过serde_v8把选项打包成BootstrapV8元组worker_bootstrap.rs结构体上的注释明确要求 “Keep this in sync with99_main.js”——即 Rust 侧的字段顺序与 JS 侧解包顺序必须一一对应。这个“Rust 元组 ↔ JS 解构”契约的 JS 一端就在 runtime/js/99_main.js整个runtime/js/目录承载了运行时引导的全部 JS 层01_version.tsDeno.version、90_deno_ns.jsDeno命名空间组装、11_workers.jsWorker全局构造、10_permissions.js权限、41_prompt.js权限提示等。Worker Web APIWebWorker 与专用 OS 线程模型README 的最后一节描述了WorkerWeb API 的实现约定源码中这三句话都能在 runtime/web_worker.rs 与 runtime/ops/worker_host.rs 中找到印证1. “WorkerAPI 由WebWorker结构体实现”——web_worker.rs 中的WebWorker持有自己的JsRuntime、name、worker_id、worker_type、main_module以及bootstrap_fn_global、poll_for_messages_fn等 JS 回调。它的Drop实现会清理 Node resolver 的线程本地package.json缓存并终止内存整理任务。2. “创建MainWorker时必须提供创建Worker的回调”——WorkerOptions::create_web_worker_cb的类型定义在 runtime/ops/worker_host.rspub type CreateWebWorkerCb dyn Fn(CreateWebWorkerArgs) - (WebWorker, SendableWebWorkerHandle);JS 侧new Worker(url)最终经 op 调用该回调回调同时返回 worker 本体与一个可跨线程的SendableWebWorkerHandle消息通道句柄宿主据此把 handle 注册进 op state 供后续postMessage使用。WebWorkerOptionsweb_worker.rs则携带了子 worker 所需的全部参数name、main_module、worker_id、独立的bootstrap: BootstrapOptions、独立的seed、stdio、worker_type等——注意create_web_worker_cb自身也被放入其中使 worker 可以递归创建孙 worker这与 README “所有WebWorker都是MainWorker的后代”的树形结构描述吻合。3. “每个WebWorker都会 spawn 一条只服务于该 worker 的 OS 线程”——worker_host.rs 中可以看到std::thread::Builder的调用先按resourceLimits若用户通过 Node 风格 API 指定了stackSizeMb或默认值设置栈大小默认DEFAULT_STACK_SIZE_MB见 worker_host.rs 的注释默认 4MB以避免与 Node 行为不一致然后thread_builder.spawn在新线程内构建WebWorker、运行其事件循环并通过create_and_run_current_thread驱动 future。新线程随后把自己的线程句柄存入WorkersTable以worker_id为键的 op state 表之后主线程与 worker 线程之间的所有交互发消息、terminate、Ctrl-C控制、CPU 用量查询都通过该表进行。这种“一 worker 一专用线程 跨线程消息通道”的架构意味着WebWorker与宿主线程之间不共享 isolate跨 worker 数据传递走postMessage序列化通道SharedArrayBuffer与编译好的 wasm 模块则通过前文提到的两个共享 store 传递。小结从 README 到源码的完整图景回到 runtime/README.md 的主张源码给出的完整证据链是定位deno_runtime0.266.0 是 CLI 的瘦身后端靠聚合 re-exportruntime/lib.rs提供 JS 执行 ops 绑定主 APIMainWorkerruntime/worker.rs封装JsRuntime与五个进程级事件分发器bootstrap_from_options保证“创建即 bootstrap”runtime/worker.rs可定制面WorkerServiceOptions提供模块加载、权限、CA 证书等依赖注入WorkerOptions提供种子、错误格式化、inspector、V8 快照等开关BootstrapOptionsruntime/worker_bootstrap.rs负责把这些配置经serde_v8同步到 runtime/js/99_main.js 完成环境引导Worker APIWebWorkerruntime/web_worker.rsCreateWebWorkerCb回调runtime/ops/worker_host.rs 每 worker 一条专用 OS 线程的线程模型构成与 Web 标准一致的Worker语义。需要再次强调 README 的稳定性警告deno_runtime的 API 会快速演进本文所述字段与方法对应当前仓库版本跨版本引用时请以该 crate 的 docs 与实际源码为准。【免费下载链接】denoA modern runtime for JavaScript and TypeScript.项目地址: https://gitcode.com/GitHub_Trending/de/deno创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
deno_runtime 运行时库剖析：MainWorker、bootstrap 流程与 WebWorker 架构（Deno 源码实战）
deno_runtime 运行时库剖析MainWorker、bootstrap 流程与 WebWorker 架构Deno 源码实战【免费下载链接】denoA modern runtime for JavaScript and TypeScript.项目地址: https://gitcode.com/GitHub_Trending/de/deno本文基于 Deno 仓库中的 runtime/README.md 展开系统讲解deno_runtimecrate 的定位与 API 设计如何以MainWorker封装deno_core::JsRuntime并注入Deno命名空间的 ops、如何完成bootstrap初始化、如何通过WorkerOptions/BootstrapOptions定制模块加载、错误格式化、V8 inspector、User-Agent、CA 证书与随机数种子等运行时属性以及WebWorker如何以“每 worker 一个专用 OS 线程”的模型实现 WebWorkerAPI。读完后你可以理解 Deno CLI 的运行时底座是如何搭建的并具备在自定义宿主中嵌入deno_runtime的工程思路。deno_runtime 是什么Deno CLI 的“瘦身版”README 对 crate 的定义非常明确它是 Deno CLI 的精简版本移除了 TypeScript 集成以及 lint、doc 等工具链本质上只保留JavaScript 执行能力加上 Deno 的操作系统绑定ops。这个 crate 发布在 crates.io 上包名为deno_runtime当前仓库中版本为0.266.0描述为 Provides the deno runtime library见 runtime/Cargo.toml。README 同时给出了一段重要的稳定性声明该 crate 由原先位于denocrate 中、久经考验的模块构建而成但其API 处于快速变化阶段随时可能发生破坏性变更。因此引用它的下游项目需要做好跟随升级的准备。从 runtime/Cargo.toml 的 features 定义可以看出该 crate 的几个编译开关它们对应不同的集成场景docsrs一个假 feature仅用于在 docs.rs 上正常生成文档exclude_runtime_main_js从导出的扩展中排除js/99_main.js适合宿主希望自行接管主模块引导逻辑的场景snapshot/transpile启用 V8 快照能力snapshot依赖transpile后者引入deno_asthmr开发特性禁用快照的创建与加载改为在运行时从磁盘读取各扩展的lazy_loaded_*源文件。它聚合了哪些能力deno_runtime自身并不从零实现 Web API而是把 Deno 的各个能力 crate 重新导出并组装。从 runtime/lib.rs 可以看到它pub use了二十多个功能模块pub use deno_cache; pub use deno_core; pub use deno_crypto; pub use deno_fetch; pub use deno_ffi; pub use deno_fs; pub use deno_http; pub use deno_kv; pub use deno_napi; pub use deno_net; pub use deno_node; pub use deno_os; pub use deno_permissions; pub use deno_process; pub use deno_web; pub use deno_webgpu; pub use deno_websocket; // ...并对外暴露了自身的关键模块code_cacheV8 代码缓存、coverage覆盖率、cpu_profilerCPU 剖析、fmt_errors错误格式化、js内置 JS 源、ops宿主 ops、permissions权限系统、snapshot快照feature 开关控制、web_worker、worker等。此外还重导出deno_features中的FeatureChecker与UNSTABLE_FEATURES用于--unstable-*特性门禁。换句话说README 所说的“JavaScript 执行 操作系统绑定”在这套 re-export 与扩展注册中得到了具体体现。主 APIMainWorkerREADME 指出该 crate 的主 API 是MainWorker一个封装了deno_core::JsRuntime、并带有一组用于实现Deno命名空间的 ops 的结构体。源码与文档一致见 runtime/worker.rs/// This worker is created and used by almost all /// subcommands in Deno executable. /// /// It provides ops available in the Deno namespace. /// /// All WebWorkers created during program execution /// are descendants of this worker. pub struct MainWorker { pub js_runtime: JsRuntime, should_break_on_first_statement: bool, should_wait_for_inspector_session: bool, exit_code: ExitCode, bootstrap_fn_global: Optionv8::Globalv8::Function, dispatch_load_event_fn_global: v8::Globalv8::Function, dispatch_beforeunload_event_fn_global: v8::Globalv8::Function, dispatch_unload_event_fn_global: v8::Globalv8::Function, dispatch_process_beforeexit_event_fn_global: v8::Globalv8::Function, dispatch_process_exit_event_fn_global: v8::Globalv8::Function, memory_trim_handle: Optiontokio::task::JoinHandle(), }从字段设计可以读出几个实现事实MainWorker的“人格”由两个回调集合构成bootstrap_fn_globalJS 侧 bootstrap 入口被bootstrap调用一次后消费和五个事件分发函数——load、beforeunload、unload、process:beforeExit、process:exit。这说明MainWorker承担了 Node 风格的进程级事件生命周期should_break_on_first_statement与should_wait_for_inspector_session对应--inspect调试场景等待调试器连接、在第一条语句处断点Drop实现会 abortmemory_trim_handle即 worker 销毁时终止周期性的内存整理任务。创建 MainWorkerbootstrap_from_optionsREADME 强调“创建MainWorker的实现者必须调用MainWorker::bootstrap来准备 JS runtime”。当前源码中这一约定收敛为组合方法bootstrap_from_optionsruntime/worker.rs先通过私有的from_options构造出 worker 和BootstrapOptions再立即调用worker.bootstrap(bootstrap_options)保证创建与初始化不可分离。from_options接收两个大参数正好对应 README 列举的可配置项1.WorkerServiceOptionsruntime/worker.rs——宿主必须提供的服务依赖字段作用module_loader: Rcdyn ModuleLoaderV8 请求加载 ES 模块时的回调实现不提供则执行代码尝试加载模块会直接报错对应 README 的“module loading implementation”permissions: PermissionsContainer权限容器多数 ops 依赖它做权限检查fs、blob_store、fetch_dns_resolver文件系统、Blob 存储、DNS 解析器root_cert_store_provider自定义根证书存储对应 README 的 “CA certificate” 定制shared_array_buffer_store多 isolate 间共享SharedArrayBuffer不提供则无法序列化compiled_wasm_module_store多 isolate 间共享已编译的WebAssembly.Modulev8_code_cache模块/脚本源码的 V8 代码缓存node_services/npm_process_state_provider可选的 Node 兼容与 npm 集成服务2.WorkerOptionsruntime/worker.rs——运行时行为参数字段作用bootstrap: BootstrapOptions注入 JS 环境的启动配置下一节详述extensions: VecExtension额外注册的扩展ops 与 JS/ESM 源若已用快照则不应重复提供已快照化的 JSstartup_snapshot: Optionstatic [u8]启动时加载的 V8 快照seed: Optionu64随机数生成器种子对应 README 的 “random number generator seed”unsafely_ignore_certificate_errors对指定域名忽略证书错误create_web_worker_cb创建WebWorker时必须提供的回调README 中 WebWorker 一节的硬性要求见后文format_js_error_fn: OptionArcFormatJsErrorFn错误格式化钩子对应 README 的 “error formatting”create_paramsisolate 创建参数例如堆内存上限wait_for_inspector_session类标志对应 README 的 “V8 inspector 与 Chrome DevTools 调试器支持”快照分支UnconfiguredRuntime 的两阶段构建WorkerOptions中还有一个值得注意的选项unconfigured_runtime当宿主如 IDE 语言服务或 LSP 场景需要复用已经创建好的运行时而不想重新构建时可以先通过UnconfiguredRuntime::new建立运行时runtime/worker.rs。它内部用PlaceholderModuleLoader占位——一个所有方法都先unwrap一个尚未插入的真实ModuleLoader的空壳随后hydrate(module_loader)把真实的加载器注入占位符并返回JsRuntime。from_options中检测到unconfigured_runtime后走hydrate分支而非现场构建扩展与 runtime并且一旦请求了trace_ops或 op metrics占位 runtime 会被丢弃回退到常规路径因为这两项必须在创建期配置。BootstrapOptions注入 JS 环境的“配置总线”bootstrap阶段真正发生的事是把BootstrapOptions序列化后传给 JS 侧执行99_main.js的引导逻辑。BootstrapOptions定义在 runtime/worker_bootstrap.rs其字段覆盖了 README 可配置清单中“进程级”的那一部分pub struct BootstrapOptions { pub deno_version: String, /// Sets Deno.args in JS runtime. pub args: VecString, pub cpu_count: usize, pub log_level: WorkerLogLevel, pub enable_testing_features: bool, pub locale: String, pub location: OptionModuleSpecifier, pub color_level: deno_terminal::colors::ColorLevel, // --unstable-* flags pub unstable_features: Veci32, pub user_agent: String, pub inspect: bool, /// If this is a deno compile-ed executable. pub is_standalone: bool, pub has_node_modules_dir: bool, pub argv0: OptionString, pub node_debug: OptionString, pub mode: WorkerExecutionMode, // Used by deno serve pub serve_port: Optionu16, pub serve_host: OptionString, pub auto_serve: bool, pub otel_config: OtelConfig, pub close_on_idle: bool, pub disable_offscreen_canvas: bool, }其中几个字段与 README 的可配置项直接对应user_agent“HTTP client user agent”定制、inspectinspector 支持、unstable_features细粒度 unstable 特性位。Default实现worker_bootstrap.rs透露了合理默认值的来源cpu_count取thread::available_parallelism()user_agent格式为Deno/{CARGO_PKG_VERSION}locale默认enmode默认WorkerExecutionMode::None。注释还特意提醒默认 user_agent 用的是 crate 版本号实现者应当提供更有意义的 UA。序列化路径也值得细看as_v8通过serde_v8把选项打包成BootstrapV8元组worker_bootstrap.rs结构体上的注释明确要求 “Keep this in sync with99_main.js”——即 Rust 侧的字段顺序与 JS 侧解包顺序必须一一对应。这个“Rust 元组 ↔ JS 解构”契约的 JS 一端就在 runtime/js/99_main.js整个runtime/js/目录承载了运行时引导的全部 JS 层01_version.tsDeno.version、90_deno_ns.jsDeno命名空间组装、11_workers.jsWorker全局构造、10_permissions.js权限、41_prompt.js权限提示等。Worker Web APIWebWorker 与专用 OS 线程模型README 的最后一节描述了WorkerWeb API 的实现约定源码中这三句话都能在 runtime/web_worker.rs 与 runtime/ops/worker_host.rs 中找到印证1. “WorkerAPI 由WebWorker结构体实现”——web_worker.rs 中的WebWorker持有自己的JsRuntime、name、worker_id、worker_type、main_module以及bootstrap_fn_global、poll_for_messages_fn等 JS 回调。它的Drop实现会清理 Node resolver 的线程本地package.json缓存并终止内存整理任务。2. “创建MainWorker时必须提供创建Worker的回调”——WorkerOptions::create_web_worker_cb的类型定义在 runtime/ops/worker_host.rspub type CreateWebWorkerCb dyn Fn(CreateWebWorkerArgs) - (WebWorker, SendableWebWorkerHandle);JS 侧new Worker(url)最终经 op 调用该回调回调同时返回 worker 本体与一个可跨线程的SendableWebWorkerHandle消息通道句柄宿主据此把 handle 注册进 op state 供后续postMessage使用。WebWorkerOptionsweb_worker.rs则携带了子 worker 所需的全部参数name、main_module、worker_id、独立的bootstrap: BootstrapOptions、独立的seed、stdio、worker_type等——注意create_web_worker_cb自身也被放入其中使 worker 可以递归创建孙 worker这与 README “所有WebWorker都是MainWorker的后代”的树形结构描述吻合。3. “每个WebWorker都会 spawn 一条只服务于该 worker 的 OS 线程”——worker_host.rs 中可以看到std::thread::Builder的调用先按resourceLimits若用户通过 Node 风格 API 指定了stackSizeMb或默认值设置栈大小默认DEFAULT_STACK_SIZE_MB见 worker_host.rs 的注释默认 4MB以避免与 Node 行为不一致然后thread_builder.spawn在新线程内构建WebWorker、运行其事件循环并通过create_and_run_current_thread驱动 future。新线程随后把自己的线程句柄存入WorkersTable以worker_id为键的 op state 表之后主线程与 worker 线程之间的所有交互发消息、terminate、Ctrl-C控制、CPU 用量查询都通过该表进行。这种“一 worker 一专用线程 跨线程消息通道”的架构意味着WebWorker与宿主线程之间不共享 isolate跨 worker 数据传递走postMessage序列化通道SharedArrayBuffer与编译好的 wasm 模块则通过前文提到的两个共享 store 传递。小结从 README 到源码的完整图景回到 runtime/README.md 的主张源码给出的完整证据链是定位deno_runtime0.266.0 是 CLI 的瘦身后端靠聚合 re-exportruntime/lib.rs提供 JS 执行 ops 绑定主 APIMainWorkerruntime/worker.rs封装JsRuntime与五个进程级事件分发器bootstrap_from_options保证“创建即 bootstrap”runtime/worker.rs可定制面WorkerServiceOptions提供模块加载、权限、CA 证书等依赖注入WorkerOptions提供种子、错误格式化、inspector、V8 快照等开关BootstrapOptionsruntime/worker_bootstrap.rs负责把这些配置经serde_v8同步到 runtime/js/99_main.js 完成环境引导Worker APIWebWorkerruntime/web_worker.rsCreateWebWorkerCb回调runtime/ops/worker_host.rs 每 worker 一条专用 OS 线程的线程模型构成与 Web 标准一致的Worker语义。需要再次强调 README 的稳定性警告deno_runtime的 API 会快速演进本文所述字段与方法对应当前仓库版本跨版本引用时请以该 crate 的 docs 与实际源码为准。【免费下载链接】denoA modern runtime for JavaScript and TypeScript.项目地址: https://gitcode.com/GitHub_Trending/de/deno创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
