Rust 1.97.1 发布：修复 LLVM 误编译，1.97.0 相关 IR 变更同步回退

Rust 官方今天发布了 Rust 1.97.1。这不是常规的小修小补，而是一次明确面向正确性的补丁更新：它修复了一个发生在 LLVM 优化阶段 的误编译问题，对应问题追踪为 rust-lang/rust#159035。官方说明里还特别提到，这个底层误编译至少从 Rust 1.87 起就已经存在，只是到了 1.97.0 里，由于 Rust 生成 IR 的某个变化，让它更容易被触发，所以这次修复不只是“补上一个上游补丁”，还把 1.97.0 中那项会放大风险的 IR 变化一起关掉了。

这类点发布最值得关注的地方，在于它直接关系到“编译成功但结果不对”这一类最难排查的问题。对于依赖 LLVM 优化结果、又比较难做端到端语义校验的项目来说，升级到 1.97.1 基本不是可选项，而是应该尽快完成的稳定性修正。官方给出的升级方式仍然很简单，已有 rustup 环境执行 rustup update stable 即可。

另外，官方也再次借这次补丁发布提醒社区：如果有条件，最好让 CI 或本地环境定期跑一下 beta / nightly，帮助更早暴露这类回归。对生态来说，这种“先在预发布通道踩出来”的能力，往往比一次补丁本身更重要。

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

Tokio 调度只保证推进不保证顺序：1M 任务实战说明应用层限流更关键

这篇关于 Tokio 的实战文章，抓住了很多人一开始容易忽略的一个点：任务被创建得早，不代表它会被更早 poll，也不代表会更早完成。作者描述的场景很典型：服务从消息队列读取事件，每个事件最多再 fan-out 出 1000 个用户 token 任务；当一次突发流量里同时进来 1000 个事件时，运行时里就会瞬间出现 约 100 万个 Tokio 任务。吞吐本身没有掉，但日志里出现了非常反直觉的现象——某些更早创建的任务，直到很后面才第一次被调度到。

文章把这个现象拆回 Tokio 的调度结构来看就很清楚了：多线程 runtime 里每个 worker 都有本地队列，本地队列溢出后会把一部分任务丢到全局队列，空闲 worker 再去偷任务。也就是说，一旦业务把“事件”拆成海量彼此独立可调度的子任务，Tokio 看到的就只剩一堆 runnable task，而不是“哪一批任务属于同一个事件”。因此，Tokio 保证的是持续推进，不是业务语义上的先来先服务。

作者最后的改法也很值得记：不是去怪 Tokio，而是在应用层用 Semaphore 给“同时进入处理中的事件数”加上边界。这样做之后，峰值内存明显降下来了，而且吞吐并没有变差。对写异步 Rust 服务的人来说，这篇文章的价值不只是理解 Tokio 调度，更是提醒你把“公平性”和“资源边界”当成应用层职责，而不是默认交给 runtime。

原文链接：https://pranitha.dev/posts/tokio-gives-progress-not-ordering/

quick-noise：稳定版 Rust 上的 SIMD 程序化噪声库，2D/3D 批量采样明显提速

quick-noise 这个新项目很容易吸引做图形、地形生成和程序化内容的人：它主打的是 稳定版 Rust 上的高性能 SIMD 噪声生成，而且从 README 里给出的基准来看，速度并不是“略快一点”，而是在多个典型场景里把现有常见方案明显甩开。比如在 1024x1024 的 3 octave FBM 测试里，quick-noise 的 grid 路径生成 Perlin 噪声只要 0.66 ms，而 FastNoise2 是 6.22 ms；batch 路径下也普遍快过 noise-rs、noiz、libnoise 等老牌方案。

项目的思路也很清晰：它同时提供 grid noise 和 batch noise 两条接口。前者面向规则网格采样，速度极高；后者支持任意坐标输入，适合 domain warping 这类更灵活的玩法。作者还专门把 API 设计成 builder 风格，既能直接 build() 生成结果，也能 fill() 进外部 slice，或者走 into_iter() 让多段噪声流水线尽量留在寄存器里完成。对性能敏感的生成任务来说，这比单纯“函数式返回 Vec”更有工程价值。

更有意思的是，它没有依赖 nightly std::simd，而是自己做了一套面向噪声场景的 SIMD 抽象，在 SSE / AVX2 / AVX512 / NEON 上工作，别的架构再退回标量路径。这意味着它一边保住了 stable Rust 的可用性，一边又给高级用户留了显式控制寄存器和指令的空间。如果后续生态验证这些 benchmark 站得住，quick-noise 很可能会成为 Rust 程序化生成领域里一个值得长期关注的新名字。

原文链接：https://github.com/Alysara/quick-noise

wasm32v1-none 向 Wgpu/Winit 打通：no_std Web 图形栈已经出现可运行示例

wgpu 生态这两天有个很值得盯住的方向：围绕 wasm32v1-none + no_std 的支持，社区已经不只是“提需求”，而是拿出了可运行的示例。gfx-rs/wgpu 的 issue 里，提案明确指出 wasm32-unknown-unknown 作为默认 WebAssembly 目标其实一直是个移动靶，Rust 对默认启用的 wasm 特性一变，浏览器兼容边界就可能跟着变；而 wasm32v1-none 的价值正在于它不默认打开那些特性，也不自带 stubbed pseudo-std，更利于把浏览器兼容范围控制在开发者自己手里。

难点当然也很现实：一旦走 no_std，就意味着 naga、wgpu 以及相关依赖都得把很多默认假设拆开重做。所以这条路暂时还远谈不上“已经成熟”。但与此同时，社区已经给出了一个示例仓库，演示 Winit + Wgpu 在 wasm32v1-none 目标上跑通 的最小路径：先手动 cargo build --target wasm32v1-none，再用 wasm-bindgen 生成 Web 绑定，而不是依赖 wasm-pack 的默认流程。

这件事的意义不在于今天就能让所有 Web 图形项目无缝切到 no_std，而在于它证明了这条路线不是纸面设想。对 Rust WebAssembly 生态来说，如果 wgpu / naga 未来真能逐步把 std 降级成 feature，而不是硬依赖，那么开发者对浏览器兼容性、目标特性和体积边界的控制权会大很多。这种基础设施层面的松绑，往往比单个 demo 更重要。

原文链接：https://github.com/gfx-rs/wgpu/issues/6826