本文是对 A dynamic linker murder mystery 的整理与翻译。
内容结构概览
- 案件背景：Rust 动态库、Go 静态库、Electron、Node.js、Chromium 同处一个进程。
- 报错现场：
cannot allocate memory in static TLS block。 - 为什么要从“第二个可执行文件”改成 native addon：本地 TCP JSON-RPC 服务容易被杀毒软件干扰。
- N-API 与 Rust glue code：用 Rust 写 Node native addon 胶水层，同时保留部分 Go 代码。
- TLS 是什么：从多线程计数器讲起，解释共享变量、Mutex、Atomic、线程本地变量。
errno为什么需要 TLS：每个线程都要有自己的错误码。- ELF 动态加载与 static TLS block：程序启动时能预留 TLS，但
dlopen运行时加载库会带来新需求。 - glibc 的 2048 字节 surplus：动态加载库时，static TLS block 有一个有限的预留空间。
- 最初的错误猜测：怀疑 Go、C 依赖或 TLS model。
- 为什么改 TLS model 不解决问题：TLS model 影响访问方式，不会减少需要分配的 TLS 大小。
- 用
readelf看 TLS segment：发现自己的.node动态库需要 4720 字节 TLS。 LD_PRELOAD为什么不适合 Node addon：提前加载会让模块初始化时机不对，无法 self-register。LD_DEBUG信息有限：动态链接器只告诉你加载失败，不会直接说谁占了 TLS。- 转向符号表排查：用
llvm-objdump -C -t看.tdata和.tbss。 - 真正凶手：
rand::rngs::thread::THREAD_RNG_KEY在.tbss中占用约 4248 字节。 - 根因链条：
backoff依赖旧rand 0.6.5，旧 rand 无条件带上rand_hc，导致巨大线程本地存储。 - 排查经验总结：
LD_DEBUG、ldd、readelf、objdump都有用，但要知道它们各自的盲区。
下面是整理好的公众号 Markdown 稿：
很多 Rust 教程都会让人产生一种错觉：代码只要能编译，事情基本就结束了。尤其是那些只用 Rust 写成、最后编译成一个单独可执行文件的小程序，确实很容易给人一种“只要 rustc 通过，世界就清净了”的感觉。
但真实工程通常没有这么简单。你的 Rust 代码可能只是系统里的一小块。它可能要链接 C 依赖，可能要被 Python、Ruby、Node.js 或 Electron 加载，可能要和 Go 代码、C++ 代码、系统动态库、第三方运行时共处一个进程。此时，Rust 的类型系统能保证一部分事情，但它管不了动态链接器的脾气。
这篇文章就是这样一个故事。项目里有一个 Rust 动态库，它链接了 Go 代码编译出来的静态库，然后作为 Node.js native addon 被 Electron 加载。Electron 自己又带着 Node.js、Chromium 以及一堆自己的动态库。所有这些东西最后都要挤在同一个 Linux 进程里。
然后某一天，程序启动时报了一个看起来非常底层、也非常不友好的错误：
Error: index.node: cannot allocate memory in static TLS block这句话就是案发现场。
一、案发背景：为什么 Electron 里会有 Rust、Go 和 native addon
事情要从一个 Electron 桌面应用讲起。这个应用最开始的架构并不是 Rust 动态库，而是 Electron 主程序加一个额外下载的本地可执行文件。桌面应用负责 UI，核心业务逻辑放在一个 Go 写的二进制程序里。第一次运行时，应用会下载这个程序，然后通过本地 TCP 端口和它做 JSON-RPC 通信。
这个设计有一些优点。比如核心逻辑可以单独更新，不用每次都更新整个 Electron 应用；服务进程也可以独立重启；Go 写网络和系统逻辑也比较方便。
但它有两个现实问题。
第一，Windows 上的第三方杀毒软件非常不喜欢这种行为：一个桌面应用第一次运行时下载另一个可执行文件，然后那个可执行文件监听本地 TCP 端口。哪怕这个端口只绑定到127.0.0.1，杀毒软件也可能认为这很可疑。大部分用户可能没事，但一旦遇到被拦截的用户，问题就很难排查。
第二，不想继续写更多 Go 代码。已有 Go 代码暂时不想全部重写，但新胶水层不想再继续堆 Go，也不想写大量 C/C++。
于是架构开始转向 Node.js native addon。
Node.js 和 Electron 支持 native addon。简单说，你可以写一段 C/C++ 代码，把它编译成动态库，然后把扩展名改成.node，接着在 JavaScript 里用require()像加载普通模块一样加载它。后来的 N-API 提供了比较稳定的 ABI，让 native addon 不必每换一个 Node 版本就重新编译一次。
于是新的方案变成：用 Rust 写 native addon 胶水层，通过 N-API 暴露给 Node/Electron；现有的大量 Go 代码暂时继续保留，但编译成静态库，链接进这个 Rust 动态库里。最后产物是一个.node文件，由 Electron 加载。
看起来比原来干净很多。没有额外下载的可执行文件，没有本地 TCP 端口，没有 JSON-RPC 服务进程。只是进程内部的函数调用。只要编译、链接、加载成功，理论上就稳了。
当然，前提是动态链接器愿意配合。
二、动态链接器开始不高兴
新的 native addon 方案一开始进展顺利。Rust 没有官方的 N-API 支持，但可以参考已有 crate 和 C API，自己把必要部分接起来。Go 和 cgo 也通过一堆编译链接参数，最终被塞进同一个动态库里。这个动态库既是一个合法的 Node.js module，又包含了 Rust 胶水层和 Go 业务逻辑。
问题出现在某次小改动之后。那次只是移植桌面应用的自更新逻辑，添加了几十行发 HTTP 请求的代码。前一天还可以编译、链接、加载；第二天突然变成：
Error: index.node: cannot allocate memory in static TLS block这不是普通 Rust panic，也不是段错误，也不是 Node.js JavaScript 异常。它发生在加载 native addon 的时候，也就是动态链接器试图把.node文件加载进进程时。
“TLS” 这个词很容易让人想到网络安全里的 Transport Layer Security，也就是 HTTPS 那个 TLS。但这里完全不是那回事。这里的 TLS 是 Thread-Local Storage，线程本地存储。
要理解这个错误，必须先理解为什么程序需要线程本地存储。
三、从多线程计数器理解 TLS
假设有五个线程，每个线程把同一个计数器加一千次。直觉上最后应该得到 5000。
如果用一个不安全的全局变量或裸指针去做这个事情，很可能每次运行都得到不同结果，比如 2796、2507、1615。原因是多个线程同时读写同一个内存位置，更新操作不是原子的，会互相覆盖。这就是经典的数据竞争问题。
Rust 的安全代码会阻止你随便这样做。你可以用：
usestd::sync::{Arc,Mutex};fnmain(){letcounter=Arc::new(Mutex::new(0_usize));letmuthandles=vec![];for_in0..5{letcounter=counter.clone();handles.push(std::thread::spawn(move||{for_in0..1000{*counter.lock().unwrap()+=1;}}));}handles.into_iter().for_each(|h|h.join().unwrap());println!("counter = {}",counter.lock().unwrap());}这样每次都能得到 5000。Arc负责跨线程共享所有权，Mutex负责互斥访问。
如果只是一个整数计数器，Clippy 还会提醒你可以考虑AtomicUsize。原子操作通常比 Mutex 更轻量：
usestd::sync::atomic::{AtomicUsize,Ordering};staticCOUNTER:AtomicUsize=AtomicUsize::new(0);但如果继续追求性能，还可以换一个思路：不要让每个线程每次都抢同一个计数器。每个线程先在自己的局部变量里累加 1000，最后主线程把所有结果相加。这样没有锁，也没有原子操作。
这就引出 TLS 的基本思想：有些数据不应该是全局共享的，而应该每个线程各有一份。每个线程访问的是自己的那份，不需要抢锁，也不会互相覆盖。
Rust 里可以用thread_local!宏表达：
usestd::cell::RefCell;thread_local!{staticCOUNTER:RefCell<usize>=RefCell::new(0);}fncounter_inc(){COUNTER.with(|c|*c.borrow_mut()+=1);}fncounter_get()->usize{COUNTER.with(|c|*c.borrow())}每个线程都有自己的COUNTER。线程 A 加的是线程 A 的计数器，线程 B 加的是线程 B 的计数器。这就是 thread-local storage。
四、errno为什么也需要 TLS
C 语言里的errno是 TLS 的经典例子。
比如fopen失败时会返回NULL：
FILE*fopen(constchar*pathname,constchar*mode);但返回NULL只能说明失败，不能说明为什么失败。文件不存在？权限不足？磁盘满了？路径太长？具体错误需要从errno里读。
问题是，多线程程序里可能有多个线程同时调用fopen。如果errno是一个普通全局变量，线程 A 的错误可能被线程 B 覆盖，结果每个线程看到的错误码都不可靠。
所以errno最终也需要每个线程一份。在现代 Linux/glibc 系统里，它可以表现得像一个普通全局变量，但实际上是线程本地的。每个线程访问的都是自己的errno。
这类需求很多。线程本地存储不是语言玩具，而是系统库、运行时、标准库、随机数生成器、异步运行时等都会用到的基础能力。
五、ELF 动态加载和 static TLS block
Linux 上，程序启动时，内核和动态加载器会做很多事情：
映射主程序 ELF 文件 解析 ELF header 加载它依赖的动态库 递归加载这些动态库的依赖 处理重定位 准备运行时环境 最后才开始执行程序入口在程序真正开始执行之前，动态加载器大体上知道当前要加载哪些库，也能知道这些库需要多少线程本地存储。于是它可以为每个线程分配一块 TLS 区域。
但问题是，程序启动后还可以通过dlopen动态加载新的动态库。Node.js native addon 就是这种场景：Electron/Node 进程先启动，后来 JavaScript 代码执行require("./index.node")，Node 再通过动态加载机制把.node文件加载进来。
那么，如果这个后来加载的动态库也需要 TLS，该怎么办？
glibc 的做法之一是预留一点额外空间。文章里提到 glibc 的源码里有一个 static TLS block surplus，大约 2048 字节。也就是说，程序启动时除了已经知道需要的 TLS，还额外多留一点，以备运行时dlopen进来的库使用。
听起来合理，但问题也来了：
2048 字节真的够吗？答案是：不一定。
而这次遇到的错误，本质就是后来加载的.node动态库需要的 static TLS 空间超过了预留额度。
六、第一轮猜测：是不是 Go 或 C 依赖吃掉了 TLS
看到错误后，第一反应是怀疑 Go。这个.node文件里链接了大量 Go 代码，会不会 Go runtime 用了很多 TLS？也许之前刚好没超过限制，这次新增几十行 Rust HTTP 代码后超过了？
查资料后发现，Go 本身并没有传统意义上的 thread-local storage。Go 的设计里 goroutine 和线程关系复杂，thread locals 对 Go 不是特别适配。
那会不会是某个 C 依赖？Rust 动态库链接了 Go，Go 又可能通过 cgo 链接 C，Rust 这边也可能依赖一些 C 库。到底哪个库需要 TLS？
于是开始检查动态库依赖。可以用ldd看.node文件依赖哪些动态库，再对每个库跑readelf -Wl看有没有 TLS segment。脚本大致思路是：
let{execSync}=require("child_process");letcmdLines=(command)=>{returnexecSync(command,{encoding:"utf-8"}).split("\n");};for(letlineofcmdLines(`ldd${process.argv[2]}`)){lettokens=line.split("=>");if(tokens.length==2){letmatches=/[^\s]+/.exec(tokens[1]);if(matches){letpath=matches[0];letheader="";for(letlineofcmdLines(`readelf -Wl "${path}"`)){if(/PhysAddr/.test(line)){header=line;}if(/TLS/.test(line)){console.log(`====${path}====`);console.log(header);console.log(line);}}}}}结果只看到libc.so.6有 TLS，MemSiz是0x90，也就是 144 字节。这很合理，而且 Electron/Node 本身早就依赖 libc，它不应该算进后来dlopen的 2048 字节 surplus 里。
所以不是某个明显外部动态库。
七、第二轮猜测：改 TLS model 有没有用
接着怀疑 TLS model。
ELF TLS 有几种模型，比如：
local-exec initial-exec local-dynamic global-dynamic不同模型有不同限制和性能特征。比如initial-exec很快，因为线程本地变量的偏移可以在程序启动时确定；但它要求这些 TLS 变量在程序初始加载时就已知。运行时dlopen加载的动态库，如果使用这种模型，就很容易出问题。
Rust 有一个不稳定参数可以控制 TLS model：
[build] rustflags = ["-Z", "tls-model=global-dynamic"]于是尝试把 TLS model 改成global-dynamic。但这没有解决问题。
原因是：TLS model 主要影响代码生成时使用什么访问方式、什么 relocation。它并不会减少这个动态库本身需要的 TLS 大小。该分配多少 TLS 还是要分配多少。并且 position-independent code 默认往往已经使用适合动态加载场景的模型，否则动态库里访问errno这类 TLS 变量都会出问题。
所以到这里，可以确认两件事：
改 TLS model 不解决问题 问题不在某个明显的外部动态库那么，只能回过头看自己的.node文件到底需要多少 TLS。
八、真正的大数字：自己的动态库需要 4720 字节 TLS
用readelf查看.node文件本身的 TLS segment：
readelf -Wl ./artifacts/linux-x86_64/index.node | grep -E 'PhysAddr|TLS'结果里MemSiz是：
0x001270换算成十进制是 4720 字节。
这已经明显超过 glibc 预留的 2048 字节 surplus。也就是说，这个动态库本身需要的 TLS 空间就太大了。
但这还没回答最关键的问题：
到底是谁在这个动态库里占用了这么多 TLS？九、LD_PRELOAD和LD_DEBUG都没能直接破案
遇到 static TLS block 不够，有一种常见 workaround：用LD_PRELOAD提前加载那个动态库。这样它不再是运行时dlopen的“后来者”，而是在程序启动时就被加载，动态加载器可以在初始 TLS 布局里考虑它。
但对于 Node native addon，这条路不通。
.node文件不是普通动态库，它有模块初始化逻辑。Node 加载它时，会调用初始化函数，让模块向 Node runtime 注册自己。如果用LD_PRELOAD在 Node 自己还没准备好之前提前加载.node，初始化函数会在错误时机执行，模块无法正常 self-register。最后报错会变成：
Module did not self-register也就是说，预加载绕开了 TLS 问题，但破坏了 Node addon 的加载语义。
再尝试LD_DEBUG=all。这是 Linux 动态链接器提供的调试输出，可以看到很多加载、符号解析、版本检查、重定位处理信息。它确实打印了很多内容，也显示.node加载失败，然后销毁 link map。但它没有告诉你到底哪个符号、哪个 TLS 变量占了太多空间。
这时调查陷入僵局。动态链接器说“不能分配 static TLS block”，但不告诉你谁是凶手。
直到开始看符号表。
十、转向符号表：.tdata和.tbss
ELF 里 TLS 数据通常会放在.tdata和.tbss这类 section 中。
.tdata是已初始化的线程本地数据。.tbss是未初始化的线程本地数据，类似普通.bss，只不过是 thread-local 的。
先用objdump看.tdata，但 Rust 符号名被 mangling 过，很难读。换成llvm-objdump -C -t，加上-C做 demangle，输出可读很多：
llvm-objdump -C -t ./artifacts/linux-x86_64/index.node | grep -F '.tdata'结果里看到一些 tokio 相关的 TLS 小变量，比如：
tokio::runtime::enter::ENTERED tokio::coop::CURRENT它们只占很少字节，不像凶手。
接着看.tbss：
llvm-objdump -C -t ./artifacts/linux-x86_64/index.node | grep -F '.tbss'这里终于出现了异常大户：
rand::rngs::thread::THREAD_RNG_KEY它占用大小是：
0x1098也就是 4248 字节。
这基本就破案了。整个动态库需要 4720 字节 TLS，其中rand::rngs::thread::THREAD_RNG_KEY一个变量就占了 4248 字节。凶手就是rand相关的线程本地随机数生成器。
十一、为什么 rand 会占这么多 TLS
看到rand之后，事情还没完全结束。现代randcrate 默认线程 RNG 并不一定会占这么夸张的 TLS。问题出在旧版本。
文章里最终查到，rand 0.7.x在非 Wasm 平台默认使用rand_chacha。但更旧的rand 0.6.5会无条件依赖多种 RNG，包括rand_hc。而rand_hc的线程本地状态比较大，导致.tbss里出现了巨大 TLS 变量。
那为什么项目里会有旧的rand 0.6.5？
依赖链条来自backoffcrate。项目前面为了自更新逻辑、HTTP 请求和重试机制，引入了相关依赖，而backoff依赖旧版本rand。于是一个看似无害的“加几十行 HTTP 请求代码”，最终把旧 rand、rand_hc、大 TLS 状态带进了 native addon。
这也解释了最初的疑问：为什么代码库昨天还能加载，今天只是加了一点 HTTP 逻辑就不能加载？因为新增依赖改变了依赖图，带来了一个巨大 thread-local RNG 状态，最终让.node文件的 static TLS 需求超过 glibc 给运行时dlopen预留的空间。
十二、为什么这个问题这么难查
这个问题难查，有几个原因。
第一，它不是编译错误。Rust 编译成功了，Go 编译成功了，链接也成功了。产物是一个合法动态库。
第二，它不是运行时崩溃。没有 segfault，没有 backtrace，没有 panic。Node.js 只是捕获到动态加载失败，然后干净退出，退出码是 1。
第三，错误发生在动态链接阶段。你的代码甚至还没真正执行。调试器、日志、普通应用层错误处理都很难派上用场。
第四，依赖链条间接。直接改动是“加 HTTP 请求”，真正影响是引入backoff，backoff引入旧rand，旧rand引入rand_hc，rand_hc使用巨大 TLS。中间隔了好几层，很难凭直觉猜到。
第五，工具各有盲区。ldd只能看动态库依赖，看不到静态链接进来的 Rust crate。LD_DEBUG能看动态加载过程，但不会告诉你哪个 TLS symbol 太大。readelf能看 TLS segment 总大小，但不能直接告诉你具体 Rust 符号。最后必须用objdump或llvm-objdump看 section 符号表，才找到真正大户。
十三、这次排查中用到的工具
这篇文章最后总结了几个排查动态链接问题的工具。
第一个是LD_DEBUG=all。它可以跟踪 Linux 动态链接器的行为，看到库加载、版本检查、重定位处理等信息。它不一定能直接告诉你答案，但通常是一个很好的起点，比单纯看到“加载失败”有用。
第二个是ldd。它是经典工具，可以列出一个 ELF 文件的动态库依赖。但要注意，ldd只能列直接动态依赖，而且动态库本身还可能依赖别的动态库。更重要的是，它看不到运行时通过dlopen加载的东西，也看不到静态链接进当前动态库里的 Rust crate 或 Go 代码。
第三个是readelf。它能查看 ELF program headers、sections、relocations 等信息。排查 TLS 时，可以用它看有没有 TLS segment，以及MemSiz到底多大。
第四个是objdump或llvm-objdump。它能看符号表，尤其配合-Cdemangle Rust/C++ 符号后，非常适合从.tdata、.tbss中找具体 TLS 变量。最终就是靠它定位到了rand::rngs::thread::THREAD_RNG_KEY。
第五个其实不是工具，而是人。动态链接和 TLS 这类问题容易让人陷入错误猜测。和另一个懂链接器的人交换思路，常常能打破僵局。这类问题不适合一个人硬扛到天亮。
十四、从 Rust 角度看，这个问题有什么启发
这件事很容易被误解成“Rust 的问题”或“rand 的问题”。其实更准确地说，它是混合运行时、动态加载和 ELF TLS 机制共同作用下暴露出来的问题。
Rust 本身没有做错。thread_local!是合法能力，rand使用 thread-local RNG 也有合理动机。Go 静态库、Electron、Node.js、Chromium、N-API，也都各有自己的合理性。问题在于它们被组合到一个复杂加载场景中：一个运行中的 Electron/Node 进程通过dlopen加载一个.node动态库，而这个库需要大量 static TLS。
对于普通 Rust 可执行程序，情况可能完全不同。程序启动时所有依赖一起加载，动态加载器可以从一开始就知道需要多少 TLS，不一定触发这个 2048 字节 surplus 限制。也就是说，同一份 Rust 代码编译成普通可执行文件可能没问题，编译成被 Node.js 运行时加载的动态库就出问题。
这就是系统工程里常见的“上下文相关”问题。代码没变，部署形态变了，运行时环境变了，问题就出现了。
十五、如果遇到类似问题，可以怎么排查
遇到：
cannot allocate memory in static TLS block可以按下面思路排查。
先确认加载方式。这个库是不是通过dlopen运行时加载？是不是 Node native addon、Python extension、Ruby extension、plugin、Electron addon？如果是，它就可能受 static TLS surplus 限制影响。
然后用readelf -Wl看目标动态库本身的 TLS segment：
readelf -Wl ./yourlib.so | grep -E 'PhysAddr|TLS'重点看MemSiz。如果数值已经超过几 KB，就值得继续查具体符号。
接着看.tdata和.tbss：
llvm-objdump -C -t ./yourlib.so | grep -F '.tdata' llvm-objdump -C -t ./yourlib.so | grep -F '.tbss'看哪些符号占用特别大。Rust 符号要用-Cdemangle，否则很难读。重点关注类似thread_rng、runtime context、thread local cache、large buffer 等名字。
再查依赖链。用cargo tree看哪个 crate 引入了相关依赖。比如这次是backoff引入旧rand。如果是旧依赖，可以升级、替换、禁用 feature，或者避免使用会带来巨大 TLS 的实现。
如果只是想临时验证，LD_PRELOAD有时能绕开 static TLS surplus，但它不一定适用于所有场景。对于 Node addon 这种需要正确初始化时机的模块，预加载可能会让模块无法注册，反而变成另一个错误。
最后，不要误以为 TLS model 参数一定能解决问题。TLS model 改变的是访问线程本地变量的方式和 relocation 模型，不一定减少 TLS 空间需求。如果问题是“占用太大”，根因还是要找到大 TLS symbol。
十六、这篇文章真正讲的是什么
表面上，这是一篇动态链接器排障文章。更深一层，它讲的是现代软件组合的复杂性。
一个 Electron 应用里有 JavaScript、Node.js、Chromium、Rust、Go、C、系统动态库、native addon、CI 构建、npm install 下载 native bits。每一层单独看都合理，但组合起来后，一个很小的依赖变化就可能在最底层的 ELF TLS 分配机制里爆炸。
它也说明“编译通过”只是工程链路中的一站。对普通 Rust 可执行文件来说，编译通过确实让人很安心；但对动态库、插件、FFI、语言运行时嵌入场景来说，还要过链接器、动态加载器、宿主运行时、ABI、初始化时机、线程模型、TLS 分配这些关。
这篇文章的标题叫“动态链接器谋杀案”，并不是为了夸张。排查过程确实像侦探故事：一开始只看到尸体，也就是加载失败；然后怀疑 Go，怀疑 C 依赖，怀疑 TLS model，怀疑动态库；走过ldd、readelf、LD_PRELOAD、LD_DEBUG；最后翻符号表，在.tbss里找到了真正的凶手。
最终破案链条是：
新增 HTTP/重试相关代码 -> 引入 backoff -> backoff 依赖 rand 0.6.5 -> rand 0.6.5 无条件带入 rand_hc -> rand_hc 的 thread-local RNG 状态很大 -> .node 动态库需要约 4720 字节 TLS -> 超过 glibc 为 dlopen 预留的 static TLS surplus -> Node/Electron 加载失败这条链条就是整篇文章最核心的技术结论。
十七、总结
这篇文章从一个 Electron 桌面应用的架构改造讲起。原先的方案是 Electron UI 加一个 Go 写的本地 JSON-RPC 服务进程，但这种“第一次运行下载可执行文件、监听本地 TCP 端口”的方式容易被 Windows 杀毒软件干扰，也带来很多排查困难。于是项目转向 Node native addon：用 Rust 写 N-API 胶水层，把已有 Go 代码编译成静态库并链接进 Rust 动态库，最后生成一个.node文件给 Electron/Node.js 加载。
新方案一开始顺利，但在添加少量 HTTP 请求相关代码后，加载 native addon 时突然报错：
cannot allocate memory in static TLS block为了理解这个错误，文章先解释了 thread-local storage。多线程共享计数器需要锁或原子操作，但有些数据更适合每个线程各有一份，比如errno。TLS 让每个线程拥有自己的变量副本，既避免共享冲突，也能提高某些场景下的访问效率。
在 Linux ELF 动态加载机制中，程序启动时动态加载器能为已知库分配 TLS，但运行时通过dlopen加载的新动态库也可能需要 TLS。glibc 会在 static TLS block 中预留一小段 surplus，大约 2048 字节，给后来加载的库使用。但如果后来加载的库需要的 static TLS 超过这个额度，就会触发报错。
排查一开始怀疑 Go、C 依赖和 TLS model，但都不是根因。用readelf看.node文件本身，发现它需要0x1270字节 TLS，也就是 4720 字节，已经明显过大。LD_PRELOAD不适用于 Node addon，因为提前加载会让模块初始化时机不对，导致 “Module did not self-register”。LD_DEBUG=all能提供动态加载过程信息，但没有直接指出哪个变量占用了 TLS。
最终通过llvm-objdump -C -t查看.tdata和.tbss符号表，发现.tbss中的rand::rngs::thread::THREAD_RNG_KEY占用了0x1098字节，也就是 4248 字节。继续追依赖链，发现backoffcrate 依赖旧版rand 0.6.5，而旧版 rand 无条件带入rand_hc，它的线程本地 RNG 状态很大。于是破案：新增的 HTTP/重试逻辑把旧 rand 链接进 native addon，导致 TLS 占用超过 glibc 的 static TLS 预留空间，最终 Electron/Node.js 无法加载.node文件。
这篇文章的经验是：动态链接问题不能只靠直觉。LD_DEBUG、ldd、readelf、objdump都有价值，但每个工具都有盲区。ldd看动态依赖，不能看到静态链接进来的 Rust crate；readelf能看到 TLS segment 大小，但不告诉你具体符号；objdump能把.tdata、.tbss里的 TLS 符号列出来，配合 demangle 才能找到真正凶手。
更大的启发是：当 Rust 代码进入真实工程环境，尤其是动态库、FFI、插件、Electron、Node.js、Go 静态库混合场景时，“能编译”远远不够。它还必须能被宿主运行时正确加载，能和动态链接器、TLS、ABI、初始化顺序和平相处。系统工程的问题常常不在某一行代码，而在依赖图、加载方式和运行时机制的交叉处。