musl静态链接后报“not found”并非链接失效，而是ldd误判（musl二进制无需动态加载器）；真正原因多为运行时环境缺失、内核不兼容、rust-std组件未安装、VSCode调试配置不当或jsonwebtoken未启用rust_crypto feature。
为什么 musl 静态链接后在 Linux 上仍报“not found”？
不是链接没生效，而是 ldd 误判了——musl 编译出的二进制根本不用动态加载器，ldd 在 glibc 环境下跑会直接报错或显示 “not a dynamic executable”。真正的问题往往藏在运行时环境缺失或路径权限上。
- 用
file your_binary确认输出是否含statically linked（而非dynamic） - 用
./your_binary直接执行，别依赖ldd判断可运行性 - 如果报
No such file or directory，大概率是内核不兼容（比如用了较新的系统调用，而目标机器内核太旧）
rustup target add x86_64-unknown-linux-musl 失败或 rust-std 缺失
安装 musl target 不等于自动装好 rust-std 组件，缺它会导致编译通过但运行时 panic：找不到 std::io 或 std::env 等基础符号。这不是代码问题，是工具链残缺。
- 先检查：运行
rustup component list --installed | grep musl，确认有rust-std-x86_64-unknown-linux-musl - 若缺失，必须手动加：
rustup component add rust-std-x86_64-unknown-linux-musl - VSCode 中 Rust Analyzer 默认只读取 host target（如
x86_64-pc-windows-msvc），不会自动感知 musl target，所以编辑时无报错但构建失败——需在cargo.toml显式指定[profile.release]下的codegen-units = 1并启用lto = true，避免优化干扰符号解析
VSCode 调试器无法 attach musl 二进制
lldb 和 gdb 默认依赖 glibc 的调试信息格式，musl 生成的 DWARF 符号虽存在，但部分调试器版本（尤其是 Windows 上的 VSCode Remote - SSH 连 Linux）会跳过或解析失败，表现为断点不命中、变量显示 <optimized out>。
- 优先用
cargo run --target x86_64-unknown-linux-musl替代 VSCode 内置调试器启动 - 若必须调试，确保目标 Linux 机器装的是
gdb-musl（非系统默认 gdb），或改用rr录制重放：rr record ./your_binary - 在
launch.json中禁用源码映射校验：添加"sourceFileMap": { "/workspace": "${workspaceFolder}" }，避免因路径差异导致符号加载失败
JSON Web Token 加密后端未启用导致 musl 构建后 panic
musl 环境下 jsonwebtoken v10+ 无法 fallback 到默认加密后端，一旦没开 rust_crypto feature，程序一碰 JWT 就 panic，且错误信息不提示缺失 feature，只报 CryptoProvider not installed —— 容易误以为是 musl 本身问题。
- 检查
Cargo.toml是否明确启用了 feature：jsonwebtoken = { version = "10.3.0", features = ["rust_crypto"] } - 不要依赖
default-features = false后再单独加，musl 下某些 feature 依赖链会被截断，必须显式声明 - 验证方式：在 musl 构建后加一行
println!("{:?}", jsonwebtoken::crypto::get_default_backend());，正常应输出RustCrypto；若 panic，说明 feature 没生效
musl 静态链接真正的难点不在编译，而在运行时上下文不可见——没有 strace 权限、没有 ldd 反馈、调试器沉默，所有线索都得靠 file、readelf -d 和最小化复现来交叉验证。
