用 cargo-llvm-lines 定位泛型膨胀：从 3.4 万行 IR 砍到 9 千
场景很具体：Rust 1.78 stable，x86_64-unknown-linux-gnu，一个内部序列化库，产物 release + lto=thin。业务侧反馈编译要 4 分半，我拿 cargo-llvm-lines 量了一下，最热的单态化函数一个就有 3.4 万行 LLVM IR，光这一个符号占全 crate 的 18%。
Rust — 系统编程语言 Rust 的讨论与实战
cargo doc 私有项漏文档，我用 RUSTDOCFLAGS 卡住 CI
workspace 里 14 个 crate，Rust 1.75，CI 是 GitHub Actions 的 ubuntu-latest。有次合并前跑 `cargo doc --workspace --no-deps`，本地干净通过，第二天同事在 `pub(crate)` 的模块里发现一个函数签名改了文档没改，链接直接 404。原因是默认 rustdoc 不检查私有项，那些只在 crate 内部用
用 cargo udeps 清掉了一个没人用的 dev-dependency
项目是 Rust 1.79、Linux x86_64、workspace 下 14 个 crate，编译一次 release 大概 6 分钟。某次改 Cargo.toml 时发现某个 crate 的 dev-dependencies 里躺着 criterion，但那个 crate 根本没有 bench 目录，测试文件里也没出现 Criterion。手写 grep 太容易漏，尤其宏和重导出之后，名字
cargo fmt 在 workspace 里漏格式化了一个 crate
workspace 下 11 个 crate，rustfmt 1.7.0（随 rust 1.74 stable 的 toolchain），CI 跑 `cargo fmt --all -- --check` 一直是绿的。上个月有人改了 `crates/ingest` 里一个 400 多行的 match，本地手写缩进乱了，CI 依旧绿。
用 cargo bloat 查出 1.2MB 的泛型实例化膨胀
项目背景：Rust 1.79，x86_64-unknown-linux-gnu，release 带 strip=true 和 lto="thin"，最终二进制 3.8MB。用户反馈冷启动慢，我用 `cargo bloat --release --crates` 看了下，发现两个业务 crate 的函数段合计 1.2MB，比预想高一个量级。
用 cargo tree 的 -i 反向查一个 trait 被谁引入
前阵子在一个 1.78 的 workspace 里遇到个怪事：某个小 crate 单独编译没问题，放进 workspace 就报 trait 方法不存在，错误指向的是 `serde::de::Deserialize`，但代码里根本没直接写这个路径。整个 workspace 大约 40 个成员，依赖树深到 cargo build 输出里滚了快两屏。
用 cargo tree 揪出重复依赖导致编译变慢
项目是 Rust 1.76，Linux x86_64，workspace 里 14 个 crate，`cargo build` 冷编译要 3 分 40 秒。症状是改一行业务代码，重新编译也要 40 多秒，而改动本身只碰一个叶子 crate。
Rust 里用 jemalloc 后 RSS 涨了 40% 的一次定位
场景是一个长跑的数据摄入服务，Rust 1.76，x86_64 Linux 5.15 容器，镜像基于 debian-slim。进程常驻，每批处理约 200 万条记录，单批峰值堆上大概 3~4 GB，跑几天后 RSS 稳定在 7 GB 左右。我为了压住内存碎片，把分配器从系统 malloc 换成了 tikv-jemallocator，结果 RSS 反而涨到接近 10 GB，容器 OOM 直接打回原形
用 sccache 把 Rust 增量编译压到 3 秒的一次记录
环境是 Linux x86_64，rustc 1.78.0，项目 41 个 crate，主二进制 crate 依赖一半以上。全量 `cargo build` 冷启动约 4 分 20 秒，改一行业务代码后 `touch` 再编，稳定在 40 秒上下。机器是 8 核 16G，`/tmp` 在 tmpfs 上。问题不在链接慢，主要是依赖 crate 反复重编——`target/debug/deps` 里
Rust 二进制在 musl 下体积翻倍的一次排查
上周把一个内部 CLI 从 glibc 目标切到 `x86_64-unknown-linux-musl`，准备塞进 distroless 镜像。同一份代码，glibc 下 release 产物是 4.1 MB，musl 下变成 9.3 MB。不是可执行文件大小的问题，是它还要跑在内存只有 256 MB 的边车容器里，体积和启动时的页加载都得算。
用 cargo-nextest 跑异步测试时被超时坑了一次
环境是 Rust 1.79，Linux x86_64，项目里有一批 tokio 异步测试，`cargo test` 单线程跑一次大约 3 分钟。为了加快反馈，我换成了 cargo-nextest（0.9.70），默认多进程并行，本地跑下来 40 秒左右。问题出在接入 CI 后：原来全绿的用例，在 nextest 里偶发失败，报错都是 `test timed out after 60s`，但同样的用
用 cargo 的 target-dir 分摊编译盘占用的一次记录
项目是 windows 上跑的，rustc 1.78，workspace 一共 11 个 crate，debug 编译完之后 target 目录 18G 左右。机器是一块 512G 的固态，系统盘只剩 30G 出头，每次 cargo build 的时候磁盘写满，链接器报错，报错信息还停在 link.exe 那一层，看不出是盘的问题。