Rust 1.97.0 发布：v0 符号改名默认开启，Cargo 原生接管 warnings 失败策略

Rust 1.97.0 这次最值得开发者立刻感知的变化，不只是一次常规稳定版更新，而是把几个会直接影响工程工作流的能力一起推到了默认路径里。最核心的一项，是 v0 symbol mangling 终于在 stable 默认开启。Rust 过去沿用接近 Itanium ABI 的改名方案，但它在泛型实例信息保留、一致性和可读性上一直有历史包袱；现在默认切到 Rust 自己的 v0 方案，意味着符号信息表达更完整，调试、反混淆和跨工具链处理也更统一了。

另一个很实用的改动，是 Cargo 终于能原生控制 warnings 是否导致构建失败。过去大家在 CI 里常用 RUSTFLAGS=-Dwarnings 这类方式硬拦，但那会把构建缓存策略也一起搅进来。1.97 把这件事交还给 Cargo 配置层：既可以 allow 暂时静音，也可以在 CI 里直接 deny，同时不破坏底层 build cache。这对大型 workspace 或重构中的项目很关键，因为团队终于能把“警告策略”当成工作流配置，而不是临时编译器黑魔法。

第三个值得注意的点，是 linker 输出不再默认被隐藏。Rust 团队把以前“链接成功就安静吞掉 linker stderr”的做法改了，转而把真实的 linker 消息作为 linker_messages 警告暴露出来。表面看只是更吵一点，但它实际是在把过去会被埋掉的平台兼容、链接器参数和构建链路问题前置暴露。放在一起看，1.97 不是只补几个 API，而是在持续把 Rust 的构建、调试和工程治理体验做得更可控。

原文链接：https://blog.rust-lang.org/2026/07/09/Rust-1.97.0/

RustCrypto 性能追问：为什么纯 Rust AES-GCM 还没吃满 SIMD 和硬件加速

Sylvain Kerkour 这篇文章很适合进日报，因为它不是泛泛地说“RustCrypto 慢”，而是把问题钉在了一个很具体的工程对比上：在 AES-256-GCM 基准里，aws-lc-rs 在 x86_64 AVX-512 上能做到 16.7 GB/s，RustCrypto 大约 4.4 GB/s，而在 aarch64 上也仍然落后于预期。作者先把前提讲清楚：这并不代表 RustCrypto “不够快”或“不能用”，很多业务里它已经 fast enough；真正值得追问的是，既然 Rust 已经能写出高性能 SIMD / 硬件加速路径，为什么这个差距还存在。

文章后半段的价值，在于它把这个问题顺势展开成一篇 纯 Rust SIMD 编程与硬件加速分析。作者从 load -> compute -> store 这条最基本的数据路径讲起，解释为什么内存装载 / 写回的延迟常常比想象中更贵，为什么“把数据尽量留在寄存器里”是关键，以及 AVX-512、NEON 这类向量指令到底在帮什么忙。也正因为这样，这篇内容的意义已经不只是点评 RustCrypto，而是给 Rust 开发者补了一节很硬核的“现代 CPU 如何真正吃满”的实践课。

更有意思的是，作者还把性能问题和用户体验重新连上了：密码学实现慢，不只是吞吐数字不好看，还会直接转化成 额外功耗、发热和电池消耗。当 TLS、消息传输、磁盘加密、端侧应用都在重复做这些操作时，性能差距会在整体体验上放大。所以这篇文章真正值得关注的，不是“谁赢了 benchmark”，而是它提醒 Rust 社区：纯 Rust 高性能密码学已经不是能不能做，而是能不能把 SIMD、寄存器占用和平台特定加速真正打磨到位。

原文链接：https://kerkour.com/rustcrypto-slow-simd-rust

NASA 开源 SpaceWasm：把 WebAssembly 解释器按航天器约束重新设计一遍

SpaceWasm 最吸引人的地方，是它不是把现成 Wasm 运行时搬到航天场景里，而是先承认“航天器和普通服务器根本不是同一种内存世界”，再按这个前提重做设计。项目目标非常明确：实现一个面向 在轨飞行软件 的 Wasm 1.0 解释器，用来在资源受限、对可预测性要求极高的环境里执行 WebAssembly 模块。它把系统拆成两块：一块是边读边校验的 decoder / validator，另一块是执行期的 interpreter。

这个项目最 Rust、也最工程化的部分，在于它对 动态内存分配 的约束写得很死：所有分配都发生在固定大小页上；不能先释放再分配；页内子区域尺寸要预先固定；内存占用必须可确定；分配失败也不能 panic。README 甚至直接说明，标准 Rust alloc 即使配合自定义 allocator 也不满足这些飞行软件约束，所以 SpaceWasm 自己提供了一套数据结构来保证这些性质，而全项目里真正涉及 unsafe 的部分也被收得很窄。

它还专门强调了 streaming decode 和峰值内存控制：很多 Wasm 解释器默认要求把整个二进制一次性放进一块内存，但在航天器上，内存通常是被严格分区、用途固定的，根本没有这种挥霍空间。SpaceWasm 因此支持按块同步喂入 Wasm 数据，并在单次解码过程中完成校验和编译到内部 IR。换句话说，这不是一个“能跑 Wasm”的小玩具，而是一次把 WebAssembly 带进安全关键、确定性约束环境里的认真工程尝试。

原文链接：https://github.com/nasa/spacewasm

Garmin Tracker 开源：Rust 桌面应用把手表同步、力量训练记录和本地 SQLite 放进一套工作流

今天另一个比较接地气、也更接近“真实用户软件”的项目，是 Garmin Tracker。它不是做云端健身服务，也不是只给开发者看的库，而是一个跨平台桌面应用：用 Tauri 2 + Rust backend + React/TypeScript 前端，直接和 Garmin 手表通过 USB / MTP 连接，把活动 .FIT 文件拉到本地，再整理成可查看、可编辑的训练记录和身体测量数据。

这个项目的亮点，在于它把很多运动软件里常见的“上云再说”路线反过来了。README 里明确写着：no cloud account required。同步、解析、训练记录、通知、数据库持久化都放在本机完成，底层用 SQLite，schema 还通过版本化 DDL migration 管理。对不少更在意数据本地掌控、又不想把力量训练记录散落在多个工具里的用户来说，这种产品形态很有吸引力。

从 Rust 视角看，它也体现出一类越来越成熟的项目结构：Rust 不只是做性能热点模块，而是在桌面端承担了 设备发现 / USB 传输、.FIT 解析、数据库访问层和 Tauri 命令接口 这些核心职责，前端再围绕这些能力去组织体验。它未必是今天最“硬核底层”的项目，但它很能说明 Rust 正在越来越自然地进入面向真实用户的桌面产品层。

原文链接：https://github.com/Emiliopg91/garmin-tracker-rs