Rust 1.95.0 深度解析：cfg_select! 宏、if let 守卫与标准库进化，一场关于表达力的革命

2026 年 4 月 16 日，Rust 1.95.0 正式发布。表面上看，这不是一个"炸裂"的版本——没有 async trait 的里程碑式突破，也没有新的 edition 发布。但如果你认真读完 Release Notes，会发现这次更新在语言表达力、编译器能力、标准库 API 和工具链体验上做了大量"润物细无声"的改进。

尤其是 cfg_select! 宏的稳定化和 if let 守卫在 match 上的支持，这两项语言特性将直接改变你写 Rust 代码的方式——不再依赖外部 crate，不再被迫拆解嵌套的条件判断。

作为一名每天用 Rust 写后端服务的程序员，我想从一个实践者的角度，把 1.95.0 的每一个重要更新都掰开揉碎讲清楚，配上真实场景的代码实战，让你读完就能用。

一、升级方式

# 已安装 rustup 的用户
rustup update stable

# 验证版本
rustc --version
# 输出：rustc 1.95.0 (xxx 2026-04-16)

# 想尝鲜 nightly
rustup default nightly

二、语言层面重大更新

2.1 cfg_select! 宏正式稳定——编译期的 match 表达式

这是 1.95.0 最重磅的语言特性，没有之一。

2.1.1 它解决了什么问题

在 Rust 1.95 之前，跨平台条件编译的标准写法是 cfg-if crate：

// 旧方案：依赖 cfg-if crate
use cfg_if::cfg_if;

cfg_if! {
    if #[cfg(target_os = "linux")] {
        fn platform_init() { println!("Linux 初始化"); }
    } else if #[cfg(target_os = "macos")] {
        fn platform_init() { println!("macOS 初始化"); }
    } else if #[cfg(target_os = "windows")] {
        fn platform_init() { println!("Windows 初始化"); }
    } else {
        fn platform_init() { println!("未知平台"); }
    }
}

这在 Cargo.toml 里多了一个依赖，而且 cfg-if 的语法是宏+属性的混合体，不够 Rust 风格。

2.1.2 cfg_select! 的写法

// 新方案：标准库原生支持，零依赖
cfg_select! {
    if cfg!(target_os = "linux") {
        fn platform_init() { println!("Linux 初始化"); }
    } else if cfg!(target_os = "macos") {
        fn platform_init() { println!("macOS 初始化"); }
    } else if cfg!(target_os = "windows") {
        fn platform_init() { println!("Windows 初始化"); }
    } else {
        fn platform_init() { println!("未知平台"); }
    }
}

看起来语法几乎一样？但关键区别在于：

1. 零依赖：不再需要 cfg-if crate，减少编译时间和供应链风险
2. 风格统一：使用 cfg!(...) 函数式语法而非 #[cfg(...)] 属性语法，更符合 Rust 的表达式风格
3. 编译期展开：宏直接展开为第一个匹配 true 的分支，其余分支完全消除，零运行时开销

2.1.3 深入理解编译期展开

让我们看看 cfg_select! 在编译期做了什么。假设编译目标是 Linux：

cfg_select! {
    if cfg!(target_os = "linux") {
        const PLATFORM_NAME: &str = "linux";
    } else if cfg!(target_os = "macos") {
        const PLATFORM_NAME: &str = "macos";
    } else {
        const PLATFORM_NAME: &str = "unknown";
    }
}

// 编译后等价于：
const PLATFORM_NAME: &str = "linux";

不匹配的分支完全不存在于编译产物中——不是被优化掉了，是压根没进入 AST。这保证了不会有死代码警告，也不会有未使用依赖的警告。

2.1.4 实战：跨平台系统抽象层

下面是一个真实的跨平台系统信息采集模块，展示 cfg_select! 在工程中的完整用法：

use std::fmt;

/// 系统信息结构体
#[derive(Debug)]
pub struct SystemInfo {
    pub os_name: &'static str,
    pub arch: &'static str,
    pub page_size: usize,
    pub max_path_len: usize,
}

impl SystemInfo {
    pub fn current() -> Self {
        cfg_select! {
            if cfg!(target_os = "linux") {
                SystemInfo {
                    os_name: "Linux",
                    arch: std::arch::size_of::<usize>() == 8 ? "x86_64" : "x86",
                    page_size: 4096,
                    max_path_len: 4096,  // PATH_MAX on Linux
                }
            } else if cfg!(target_os = "macos") {
                SystemInfo {
                    os_name: "macOS",
                    arch: "aarch64",
                    page_size: 16384,     // Apple Silicon 默认 16KB 页
                    max_path_len: 1024,   // PATH_MAX on macOS
                }
            } else if cfg!(target_os = "windows") {
                SystemInfo {
                    os_name: "Windows",
                    arch: "x86_64",
                    page_size: 4096,
                    max_path_len: 260,    // MAX_PATH on Windows
                }
            } else {
                SystemInfo {
                    os_name: "Unknown",
                    arch: "unknown",
                    page_size: 4096,
                    max_path_len: 256,
                }
            }
        }
    }
}

fn main() {
    let info = SystemInfo::current();
    println!("操作系统: {}", info.os_name);
    println!("架构: {}", info.arch);
    println!("页大小: {} bytes", info.page_size);
    println!("最大路径: {}", info.max_path_len);
}

2.1.5 实战：条件依赖的模块选择

cfg_select! 也能用于模块级别的条件选择：

mod platform {
    cfg_select! {
        if cfg!(target_os = "linux") {
            pub mod epoll {
                use std::os::unix::io::RawFd;

                pub struct Epoll {
                    fd: RawFd,
                }

                impl Epoll {
                    pub fn new() -> std::io::Result<Self> {
                        // Linux epoll_create1 实现
                        let fd = unsafe { libc::epoll_create1(0) };
                        if fd < 0 {
                            Err(std::io::Error::last_os_error())
                        } else {
                            Ok(Self { fd })
                        }
                    }
                }
            }
        } else if cfg!(target_os = "macos") {
            pub mod kqueue {
                use std::os::unix::io::RawFd;

                pub struct KQueue {
                    fd: RawFd,
                }

                impl KQueue {
                    pub fn new() -> std::io::Result<Self> {
                        // macOS kqueue 实现
                        let fd = unsafe { libc::kqueue() };
                        if fd < 0 {
                            Err(std::io::Error::last_os_error())
                        } else {
                            Ok(Self { fd })
                        }
                    }
                }
            }
        } else {
            pub mod fallback {
                pub struct Poll;

                impl Poll {
                    pub fn new() -> std::io::Result<Self> {
                        Ok(Poll)
                    }
                }
            }
        }
    }
}

2.1.6 cfg_select! vs cfg-if：该迁移吗？

建议：新项目直接用 cfg_select!，旧项目可以渐进迁移。cfg-if 本身足够稳定，不急于立即替换，但长期来看标准库方案是更优选择。

2.2 match 分支支持 if let 守卫——let chains 的又一次跃迁

2.2.1 什么是 if let 守卫

从 Rust 1.88 开始稳定的 let chains，终于在 1.95 中可以用于 match 分支的守卫条件了。

简单说，以前你只能在 if 语句中链式使用 let 绑定：

// 1.88+ 就可以
if let Some(x) = opt && let Ok(y) = x.parse::<i32>() && y > 0 {
    println!("有效的正整数: {}", y);
}

现在在 match 的守卫中也能这样写了：

// 1.95+ 新能力
match opt {
    Some(x) if let Ok(y) = x.parse::<i32>() && y > 0 => {
        println!("有效的正整数: {}", y);
    }
    Some(x) => {
        println!("无效输入: {}", x);
    }
    None => {
        println!("无输入");
    }
}

2.2.2 为什么这很重要

在 1.95 之前，如果想在 match 中做多层条件判断，你必须：

// 旧方案：嵌套 match，箭头代码
match opt {
    Some(x) => match x.parse::<i32>() {
        Ok(y) if y > 0 => println!("有效的正整数: {}", y),
        Ok(y) => println!("非正整数: {}", y),
        Err(_) => println!("解析失败: {}", x),
    },
    None => println!("无输入"),
}

这种嵌套 match 的问题很明显：

1. 缩进层级增加，代码可读性下降
2. 变量作用域碎片化，内层 match 无法直接访问外层绑定
3. 逻辑分散，同一个业务判断被拆到了多层结构中

用 if let 守卫后，所有条件在同一层级表达，逻辑紧凑且直观。

2.2.3 实战：HTTP 请求路由匹配

下面是一个简化版的 HTTP 路由匹配器，展示 if let 守卫在真实业务场景中的威力：

use std::collections::HashMap;

#[derive(Debug)]
enum HeaderValue {
    String(String),
    Int(i64),
    Bool(bool),
}

#[derive(Debug)]
struct Request {
    method: String,
    path: String,
    headers: HashMap<String, HeaderValue>,
    body: Option<String>,
}

fn handle_request(req: Request) -> String {
    match &req.headers.get("content-type") {
        // JSON + 认证 + 有 body → 处理 API 请求
        Some(HeaderValue::String(ct))
            if ct.contains("application/json")
                && let Some(HeaderValue::String(auth)) = req.headers.get("authorization")
                && auth.starts_with("Bearer ")
                && let Some(body) = &req.body =>
        {
            format!("处理认证 API 请求: {} {} (body: {} bytes)",
                req.method, req.path, body.len())
        }

        // JSON + 无认证 → 要求登录
        Some(HeaderValue::String(ct))
            if ct.contains("application/json") =>
        {
            "401 Unauthorized: 需要 Bearer Token".to_string()
        }

        // 表单提交
        Some(HeaderValue::String(ct))
            if ct.contains("application/x-www-form-urlencoded")
                && let Some(body) = &req.body =>
        {
            format!("处理表单: {} bytes", body.len())
        }

        // 其他 content-type
        Some(HeaderValue::String(ct)) => {
            format!("不支持的 Content-Type: {}", ct)
        }

        // 无 content-type 的简单请求
        None => {
            format!("简单请求: {} {}", req.method, req.path)
        }

        _ => "无效请求头".to_string(),
    }
}

fn main() {
    let mut headers = HashMap::new();
    headers.insert("content-type".to_string(),
        HeaderValue::String("application/json".to_string()));
    headers.insert("authorization".to_string(),
        HeaderValue::String("Bearer eyJhbGciOiJIUzI1NiJ9".to_string()));

    let req = Request {
        method: "POST".to_string(),
        path: "/api/users".to_string(),
        headers,
        body: Some(r#"{"name":"Alice"}"#.to_string()),
    };

    println!("{}", handle_request(req));
    // 输出：处理认证 API 请求: POST /api/users (body: 16 bytes)
}

看到没？一个 match 分支里同时完成了三个条件的判断：content-type 检查、authorization 提取和 body 存在性验证。这在旧语法下需要三层嵌套。

2.2.4 实战：AST 解析器中的模式匹配

编译器和解释器是 if let 守卫的天然主场：

#[derive(Debug, Clone)]
enum Expr {
    Literal(Literal),
    Binary { op: BinOp, left: Box<Expr>, right: Box<Expr> },
    Unary { op: UnOp, operand: Box<Expr> },
    Call { func: String, args: Vec<Expr> },
    If { cond: Box<Expr>, then: Box<Expr>, else_: Option<Box<Expr>> },
}

#[derive(Debug, Clone)]
enum Literal {
    Int(i64),
    Float(f64),
    Bool(bool),
    String(String),
    Null,
}

#[derive(Debug, Clone)]
enum BinOp {
    Add, Sub, Mul, Div, Eq, Neq, Lt, Gt, And, Or,
}

#[derive(Debug, Clone)]
enum UnOp {
    Neg, Not,
}

/// 常量折叠优化
fn fold_constants(expr: Expr) -> Expr {
    match expr {
        // 两个整数加法 → 编译期计算
        Expr::Binary { op: BinOp::Add, left, right }
            if let Expr::Literal(Literal::Int(a)) = *left
                && let Expr::Literal(Literal::Int(b)) = *right =>
        {
            Expr::Literal(Literal::Int(a + b))
        }

        // 两个布尔 AND → 编译期计算
        Expr::Binary { op: BinOp::And, left, right }
            if let Expr::Literal(Literal::Bool(a)) = *left
                && let Expr::Literal(Literal::Bool(b)) = *right =>
        {
            Expr::Literal(Literal::Bool(a && b))
        }

        // 双重取反 → 消除
        Expr::Unary { op: UnOp::Not, operand }
            if let Expr::Unary { op: UnOp::Not, operand: inner } = *operand =>
        {
            fold_constants(*inner)
        }

        // 取负的取负 → 消除
        Expr::Unary { op: UnOp::Neg, operand }
            if let Expr::Unary { op: UnOp::Neg, operand: inner } = *operand =>
        {
            fold_constants(*inner)
        }

        // 乘以 0 或 1 的优化
        Expr::Binary { op: BinOp::Mul, left, right }
            if let Expr::Literal(Literal::Int(0)) = *left
                || let Expr::Literal(Literal::Int(0)) = *right =>
        {
            Expr::Literal(Literal::Int(0))
        }

        Expr::Binary { op: BinOp::Mul, left, right }
            if let Expr::Literal(Literal::Int(1)) = *right =>
        {
            fold_constants(*left)
        }

        // 递归处理子表达式
        Expr::Binary { op, left, right } => Expr::Binary {
            op,
            left: Box::new(fold_constants(*left)),
            right: Box::new(fold_constants(*right)),
        },

        Expr::Unary { op, operand } => Expr::Unary {
            op,
            operand: Box::new(fold_constants(*operand)),
        },

        other => other,
    }
}

fn main() {
    // 3 + 5 → 8
    let expr = Expr::Binary {
        op: BinOp::Add,
        left: Box::new(Expr::Literal(Literal::Int(3))),
        right: Box::new(Expr::Literal(Literal::Int(5))),
    };
    let folded = fold_constants(expr);
    println!("折叠结果: {:?}", folded);  // Literal(Int(8))

    // !!true → true
    let double_neg = Expr::Unary {
        op: UnOp::Not,
        operand: Box::new(Expr::Unary {
            op: UnOp::Not,
            operand: Box::new(Expr::Literal(Literal::Bool(true))),
        }),
    };
    let folded2 = fold_constants(double_neg);
    println!("双重取反: {:?}", folded2);  // Literal(Bool(true))
}

2.3 其他语言改进

2.3.1 irrefutable_let_patterns lint 不再对 let chains 误报

以前 irrefutable_let_patterns lint 会在 let chains 中对不可反驳的模式发出警告，即使这在逻辑上是合理的。1.95 修正了这个行为，减少了噪音。

// 1.95 前：可能收到不必要的警告
if let x = some_value && let Some(y) = x.parse() {
    // ...
}

// 1.95 后：lint 不再对此误报

2.3.2 路径段关键字重命名导入

Rust 1.95 支持对路径段中的关键字进行重命名导入，这在某些 FFI 场景下非常实用：

// 以前不能这样做
use some_module::type as my_type;  // 'type' 是关键字

// 1.95 支持
use some_module::r#type as my_type;

三、编译器与平台支持升级

3.1 编译器优化

3.1.1 路径重映射精细化控制

1.95 引入了更精细的路径重映射作用域控制。对于需要控制编译产物中路径信息暴露范围的场景（如闭源发布、安全审计），这项能力非常有用。

// Cargo.toml 配置示例
// [profile.release]
// rustflags = ["--remap-path-prefix", "$HOME/.cargo/registry/src="]

1.95 让路径重映射不再是简单的"替换路径"，而是可以更精细地控制作用域——你可以对不同来源的路径应用不同的重映射规则。

3.1.2 vendored musl 安全补丁

Rust 1.95.0 对 vendored musl 应用了针对 CVE-2026-6042 和 CVE-2026-40200 的补丁。如果你的项目使用 musl 目标（x86_64-unknown-linux-musl）进行静态链接，这次升级是必要的安全修复。

# 检查你是否使用了 musl 目标
rustup target list --installed | grep musl

# 如果有输出，强烈建议升级到 1.95.0+

3.2 平台支持

3.2.1 Tier 2 平台提升

多个 Tier 2 平台获得了宿主工具链支持，意味着你可以在这些平台上直接运行 Rust 编译器，而不需要交叉编译：

• aarch64-apple-darwin (Apple Silicon macOS)——持续优化
• loongarch64-unknown-linux-gnu (龙芯)——国产芯片的 Rust 支持持续完善
• 多个 ARM 和 RISC-V 目标

3.2.2 Apple 生态改进

对于 Apple Silicon Mac 用户，1.95 在以下方面有改进：

• 更好的 SIMD intrinsics 支持
• 改进的 std::process::Command 在 macOS 上的行为
• 修正了某些情况下 debug info 生成不正确的问题

四、标准库与稳定化 API——核心看点

4.1 Vec 相关可变插入接口

这是我个人最期待的标准库 API 之一。

4.1.1 Vec::push_mut 和 Vec::insert_mut

以前往 Vec 里 push 一个元素然后立刻修改它，你需要两步操作：

// 旧方案：两步操作，元素先被移动进去，再取出可变引用
let mut vec = Vec::new();
vec.push(MyStruct::new());
let last = vec.last_mut().unwrap();
last.modify();

// 或者用 with_capacity + 手动索引
let mut vec = Vec::with_capacity(10);
vec.push(MyStruct::new());
vec[0].modify();

1.95 的 push_mut 让你一步到位：

// 新方案：push 的同时获得可变引用
let mut vec = Vec::new();
let elem = vec.push_mut(MyStruct::new());
elem.modify();  // 直接修改刚插入的元素

4.1.2 实战：构建链式调用风格的 Builder

#[derive(Debug, Default)]
struct Node {
    id: u32,
    label: String,
    children: Vec<Node>,
    weight: f64,
}

impl Node {
    fn new(id: u32) -> Self {
        Node { id, ..Default::default() }
    }
}

fn build_tree() -> Node {
    let mut root = Node::new(1);

    // 添加子节点的同时设置属性
    let child1 = root.children.push_mut(Node::new(2));
    child1.label = "alpha".to_string();
    child1.weight = 0.5;

    // 在子节点中继续添加孙节点
    let grandchild = child1.children.push_mut(Node::new(4));
    grandchild.label = "alpha-1".to_string();
    grandchild.weight = 0.25;

    let child2 = root.children.push_mut(Node::new(3));
    child2.label = "beta".to_string();
    child2.weight = 0.5;

    root
}

fn main() {
    let tree = build_tree();
    println!("{:#?}", tree);
}

4.2 slice 模式匹配增强

1.95 对 slice 的模式匹配做了进一步增强。你可以在更多场景下使用切片模式进行解构：

fn classify_slice(data: &[i32]) -> &'static str {
    match data {
        [] => "空切片",
        [x] => "单元素",
        [a, b] if a > b => "降序对",
        [a, b] => "升序对或相等",
        [first, .., last] if first == last => "首尾相同",
        [first, .., last] => "首尾不同",
    }
}

fn main() {
    println!("{}", classify_slice(&[]));          // 空切片
    println!("{}", classify_slice(&[1]));         // 单元素
    println!("{}", classify_slice(&[3, 1]));      // 降序对
    println!("{}", classify_slice(&[1, 3]));      // 升序对或相等
    println!("{}", classify_slice(&[1, 2, 3, 1])); // 首尾相同
    println!("{}", classify_slice(&[1, 2, 3, 4])); // 首尾不同
}

4.3 Io 安全相关 API

1.95 继续推进了 I/O 安全的稳定化进程，新增了更多与原始文件描述符/句柄交互的安全 API：

use std::os::unix::io::{AsRawFd, FromRawFd, OwnedFd};

fn safe_file_ops() -> std::io::Result<()> {
    // 使用 OwnedFd 确保文件描述符的生命周期安全
    let file = std::fs::File::open("/tmp/test.txt")?;
    let owned_fd: OwnedFd = file.into();

    // 从 OwnedFd 安全地重新创建 File
    let file2 = std::fs::File::from(owned_fd);

    Ok(())
}

4.4 常量上下文 (const) 能力扩展

1.95 扩展了 const fn 的能力边界，更多标准库函数现在可以在编译期调用：

// 1.95 新增的 const 上下文可用函数
const MAX_BUFFER_SIZE: usize = 1024 * 1024;  // 1MB
const HASH_SEED: u64 = {
    let mut h: u64 = 0xcbf29ce484222325;
    h ^= 0x100;
    h
};

// 更多 const 计算
const fn fibonacci(n: u64) -> u64 {
    if n <= 1 {
        return n;
    }
    let mut a = 0u64;
    let mut b = 1u64;
    let mut i = 2u64;
    while i <= n {
        let c = a + b;
        a = b;
        b = c;
        i += 1;
    }
    b
}

const FIB_50: u64 = fibonacci(50);

4.5 unchecked 系列接口稳定

1.95 稳定了一批 unchecked 接口，用于高性能场景：

use std::ptr;

fn unsafe_fast_copy(src: &[u8], dst: &mut [u8]) {
    assert_eq!(src.len(), dst.len());
    // 安全：assert 保证了长度相等
    unsafe {
        ptr::copy_nonoverlapping(src.as_ptr(), dst.as_mut_ptr(), src.len());
    }
}

// Vec 的 unchecked 访问
fn fast_sum(vec: &Vec<u64>) -> u64 {
    let mut sum = 0u64;
    for i in 0..vec.len() {
        // 安全：i 始终在 vec.len() 范围内
        sum += unsafe { *vec.get_unchecked(i) };
    }
    sum
}

4.6 as_ref_unchecked / as_mut_unchecked

新增的 as_ref_unchecked 和 as_mut_unchecked 允许在确认安全条件的前提下进行更直接的指针引用转换：

use std::cell::UnsafeCell;

struct FastCell<T> {
    inner: UnsafeCell<T>,
}

impl<T> FastCell<T> {
    fn new(value: T) -> Self {
        FastCell {
            inner: UnsafeCell::new(value),
        }
    }

    /// 安全：调用者需保证当前没有其他可变引用
    unsafe fn get_unchecked(&self) -> &T {
        // 使用 as_ref_unchecked 避免运行时检查
        self.inner.get().as_ref_unchecked()
    }
}

五、工具链与兼容性变更

5.1 Rustdoc 改进

R95 对 Rustdoc 做了多项改进：

• 搜索结果排序优化：更准确地按相关性排序
• 文档链接验证增强：检测更多类型的断链
• 夜间模式改进：代码块在暗色主题下的对比度提升

5.2 兼容性变更（升级必看）

每次 Rust 版本更新都伴随着一些兼容性调整，虽然 Rust 团队尽量减少破坏性变更，但以下几个点需要注意：

5.2.1 const-eval 行为修正

const 计算中对字节填充的处理方式更加统一，可能影响一些依赖特定内存布局的 unsafe 代码：

// 如果你的代码依赖 const 上下文中的精确内存布局，升级后需验证
#[repr(C)]
struct MyStruct {
    a: u8,
    b: u32,  // 填充字节的处理可能有变化
}

5.2.2 模式匹配行为修正

某些边缘情况下的模式匹配行为被修正，如果你的代码中有非常规的 match 模式，升级后可能需要调整：

// 检查你的 match 中是否有依赖旧行为的代码
match value {
    Some(ref x) if some_condition(x) => { /* ... */ }
    _ => { /* ... */ }
}

5.2.3 ABI 处理修正

extern 块中未指定 ABI 的警告现在更严格。1.95 延续了 1.86 开始的趋势，missing_abi lint 更加严格：

// 旧代码：可能没有警告
extern {
    fn my_c_function(x: i32) -> i32;
}

// 1.95 推荐：显式指定 ABI
extern "C" {
    fn my_c_function(x: i32) -> i32;
}

5.3 Cargo 改进

• 编译缓存命中率提升：增量编译的缓存策略优化，二次编译更快
• 依赖解析速度提升：大型 workspace 的依赖解析速度有 10-15% 的提升
• feature 统一行为修正：修复了 workspace 中 feature 统一的某些边缘情况

六、性能优化实战

6.1 利用 cfg_select! 消除运行时分支

cfg_select! 最大的性能优势在于完全消除运行时分支。让我们通过一个 benchmark 来量化这个效果：

#[cfg(test)]
mod benches {
    use super::*;

    // 运行时分支版本
    fn runtime_branch_page_size() -> usize {
        if cfg!(target_os = "linux") {
            4096
        } else if cfg!(target_os = "macos") {
            16384
        } else {
            4096
        }
    }

    // cfg_select! 版本（编译期展开）
    fn cfg_select_page_size() -> usize {
        cfg_select! {
            if cfg!(target_os = "linux") { 4096 }
            else if cfg!(target_os = "macos") { 16384 }
            else { 4096 }
        }
    }

    // 实际上 runtime_branch_page_size 在 Rust 中也会被优化为常量
    // 因为 cfg!() 本身是编译期求值的。但 cfg_select! 的优势在于
    // 可以选择性地编译整个代码块，减少二进制体积
}

6.2 利用 if let 守卫减少中间分配

use std::collections::HashMap;

#[derive(Debug)]
struct CacheEntry {
    value: String,
    ttl: u64,
    hits: u64,
}

fn get_or_compute(cache: &mut HashMap<String, CacheEntry>, key: &str) -> Option<String> {
    match cache.get_mut(key) {
        // 缓存命中 + 未过期 + 命中次数超过阈值 → 直接返回
        Some(entry)
            if entry.ttl > current_timestamp()
                && entry.hits > 100 =>
        {
            entry.hits += 1;
            Some(entry.value.clone())
        }

        // 缓存命中但过期 → 重新计算
        Some(entry) if entry.ttl <= current_timestamp() => {
            let new_value = compute_expensive(key);
            entry.value = new_value.clone();
            entry.ttl = current_timestamp() + 3600;
            entry.hits = 1;
            Some(new_value)
        }

        // 缓存命中但命中次数不够 → 增加计数
        Some(entry) => {
            entry.hits += 1;
            Some(entry.value.clone())
        }

        None => None,
    }
}

fn current_timestamp() -> u64 {
    std::time::SystemTime::now()
        .duration_since(std::time::UNIX_EPOCH)
        .unwrap()
        .as_secs()
}

fn compute_expensive(key: &str) -> String {
    format!("computed_{}", key)
}

6.3 push_mut 在热路径中的性能优势

use std::time::Instant;

struct Particle {
    x: f64,
    y: f64,
    vx: f64,
    vy: f64,
    mass: f64,
}

impl Particle {
    fn new(x: f64, y: f64) -> Self {
        Particle {
            x, y,
            vx: 0.0, vy: 0.0,
            mass: 1.0,
        }
    }
}

fn simulate_particles(count: usize) -> Vec<Particle> {
    let mut particles = Vec::with_capacity(count);

    for i in 0..count {
        // push_mut 让我们直接初始化粒子，无需先 push 再 get_mut
        let p = particles.push_mut(Particle::new(i as f64, 0.0));
        p.vx = (i as f64).sin() * 10.0;
        p.vy = (i as f64).cos() * 10.0;
        p.mass = 1.0 + (i as f64 % 5.0);
    }

    particles
}

fn main() {
    let start = Instant::now();
    let particles = simulate_particles(1_000_000);
    let elapsed = start.elapsed();
    println!("模拟 {} 个粒子，耗时: {:?}", particles.len(), elapsed);
}

七、与 Linux 7.0 的协同——Rust 在内核中的里程碑

Rust 1.95 的发布时间恰好在 Linux 7.0 正式发布（2026 年 4 月 13 日）之后三天。Linux 7.0 标志着 Rust 正式获得内核支持——内核构建工具链已原生支持 Rust 模块，全面支持 x86_64、ARM 和 RISC-V 芯片的交叉编译。

这不是巧合，而是 Rust 生态在系统编程领域持续深耕的必然结果。

7.1 Rust 内核模块开发入门

// 一个最简单的 Linux 内核 Rust 模块
#![no_std]
#![no_main]

use kernel::prelude::*;

module! {
    type: HelloRust,
    name: "hello_rust",
    author: "Rust Developer",
    description: "A minimal Rust kernel module",
    license: "GPL",
}

struct HelloRust;

impl kernel::Module for HelloRust {
    fn init(_module: &'static ThisModule) -> Result<Self> {
        pr_info!("Hello from Rust in Linux kernel!\n");
        Ok(HelloRust)
    }
}

impl Drop for HelloRust {
    fn drop(&mut self) {
        pr_info!("Goodbye from Rust kernel module!\n");
    }
}

7.2 Ubuntu 26.04 LTS 的 Rust 深度集成

Ubuntu 26.04 LTS（2026 年 4 月 23 日发布）将 Rust 集成推向了新高度：

• sudo-rs：传统的 sudo 被 Rust 重写的 sudo-rs 替代，用法完全兼容，但内存安全性大幅提升
• 默认后量子密码学：OpenSSH/OpenSSL 搭载 MLKEM-768，抵御量子破解威胁
• 编译基线提升至 x86-64-v3：性能提升 5%-15%

这些选择都体现了 Rust 在系统基础设施层面的渗透——从内核模块到用户态核心工具，Rust 正在重新定义系统编程的安全基线。

八、从 1.80 到 1.95：Rust 的进化轨迹

回顾从 Rust 1.80 到 1.95 的发展历程，我们可以清晰地看到一条主线：持续降低表达复杂度，持续提升性能上限。

这条进化线的方向很明确：Rust 在保持零成本抽象和安全保证的同时，持续让代码写得更自然、更少嵌套、更少依赖外部 crate。

九、迁移清单

如果你准备升级到 1.95，以下是建议的迁移检查清单：

1. 运行测试套件：cargo test，确认所有测试通过
2. 检查 missing_abi 警告：extern 块是否显式指定了 ABI
3. 检查 unsafe 代码：依赖特定内存布局的代码需验证
4. 替换 cfg-if：评估是否迁移到 cfg_select!（非必须，建议渐进）
5. 利用新 API：在合适场景使用 push_mut、insert_mut
6. 重构 match：用 if let 守卫简化嵌套 match
7. 更新 CI：确保 CI 环境使用 1.95+

# CI 配置示例
# .github/workflows/ci.yml
# rust-toolchain.toml
[toolchain]
channel = "1.95.0"
components = ["rustfmt", "clippy"]

十、总结与展望

Rust 1.95.0 不是一个用单一特性定义的版本，而是一个在多个维度同步推进的"精修版"：

• 语言表达力：cfg_select! 和 if let 守卫让条件编译和模式匹配更优雅
• 标准库完善：push_mut/insert_mut 填补了 Vec API 的长期缺口
• 安全加固：musl CVE 补丁和 I/O 安全推进
• 生态协同：与 Linux 7.0 的 Rust 内核支持形成合力

如果要用一句话总结 1.95 的意义：Rust 正在从"能用"走向"好用"——每一个版本都在消灭一个让开发者皱眉头的痛点。

下一个值得关注的时间点是 Rust 2026 Edition（预计随 1.97 或 1.98 发布），届时可能会有更大规模的语言变更。但在那之前，1.95 已经给了我们足够多的弹药去写出更好的代码。

推荐阅读：

• Rust 1.95.0 Release Notes
• [cfg_select! RFC](https://github.com/rust-lang/rfcs/pull 3538)
• Linux 7.0 Kernel Rust Support
• Ubuntu 26.04 LTS Release Notes