基本类型

你刚把一个接口返回的端口号读进来，顺手写了句 let port = "8080".parse().unwrap();，编译器却不肯往下走：

error[E0284]: type annotations needed

第一次看到这种错误，很容易觉得 Rust 在管闲事。8080 不就是一个整数吗？可编译器真正追问的是：它是 u16、u32，还是可能带负数的 i32？这些类型占用的空间不同，能表示的范围不同，溢出后的处理也不同。等代码真的开始接收用户输入、处理中文、计算金额或者拆网络数据包时，“差不多是个数字”和“确定是哪一种数字”之间，会隔着一批很难排查的 bug。

这一章不打算让你背一张类型表。我们会从会出错的代码开始，再顺着编译器的提醒看 Rust 为什么这样设计。你会遇到整数边界、浮点误差、UTF-8 字符边界、固定长度数组和可能失败的类型转换。这些地方确实会卡人，尤其是字符串。先接受这种不顺手：编译器现在多问一句，通常是在替运行中的程序挡住一个更贵的问题。

类型推断能帮忙，但不能替你做业务决定

Rust 是静态类型语言。程序真正运行以前，每个值的具体类型都必须确定。好消息是，你不需要在每个变量后面都写类型；编译器会顺着字面量、函数参数、返回值和后续用法把类型推出来。

fn double(value: i64) -> i64 {
    value * 2
}
 
fn main() {
    let count = 12;          // 后面没有别的约束，默认推断成 i32
    let ratio = 0.75;        // 默认推断成 f64
    let total = double(21);  // 根据函数参数推断为 i64
 
    println!("{count} {ratio} {total}");
}

12 0.75 42

推断不是猜测。它只使用代码中已经存在的约束。如果几种类型都说得通，编译器不会替你挑一个看起来顺眼的。字符串解析就是最常见的例子：很多整数和浮点类型都实现了解析能力，单看 parse()，没有办法知道你想要哪一种。

fn main() {
    let port: u16 = "8080".parse().expect("端口必须是 0 到 65535 的整数");
    let load = "0.82".parse::<f64>().expect("负载必须是数字");
 
    println!("port={port}, load={load}");
}

你可以在变量处写 : u16，也可以在泛型方法处写 ::<f64>。两种写法都在向编译器补充同一件事：目标类型是什么。类型标注最好放在最能表达业务含义的位置。端口的变量定义处写 u16 很自然；一串临时转换连在一起时，给 parse 写类型参数往往更清楚。

字面量只是写法，类型还要看上下文

整数字面量可以写成十进制、十六进制、八进制和二进制。下划线只负责分组，不改变数值。字节字面量 b'A' 的类型固定是 u8。

fn main() {
    let daily_limit = 1_000_000u64;
    let color = 0xff_80_20u32;
    let permission = 0o755u16;
    let mask = 0b1111_0000u8;
    let ascii_a = b'A';
 
    println!("{daily_limit} {color} {permission} {mask} {ascii_a}");
}

1000000 16744480 493 240 65

后缀直接跟在字面量后面，例如 42u8、-9i64、3.5f32。写不写后缀不是“专业程度”的区别。局部计算的类型已经一眼可见时，让编译器推断更省噪音；协议字段、文件格式、数据库主键、公开函数边界这些地方，主动标注通常更稳，因为位宽本身就是约定的一部分。

有一个容易忽略的细节：同样写着 5 / 2，如果两边是整数，结果就是整数 2；写成 5.0 / 2.0，结果才是浮点数 2.5。Rust 不会看见接收变量是浮点数，就先替你把整数除法改成浮点除法。

fn main() {
    let wrong = (5 / 2) as f64;
    let right = 5.0 / 2.0;
 
    println!("wrong={wrong}, right={right}");
}

wrong=2, right=2.5

这里的坑不在转换，而在转换发生得太晚：5 / 2 已经先算成了 2，后面再变成 f64 也找不回丢掉的小数。

整数：先确定范围，再谈运算

假设你在统计失败次数，为了省一点空间用了 u8。测试时只有几次失败，一切正常；线上某台机器持续重试，计数从 255 再加一。这个值接下来是报错、变成 0，还是停在 255，不是语法细节，而是监控是否会漏报的问题。

Rust 的整数类型分成两组。有符号整数以 i 开头，可以表示负数；无符号整数以 u 开头，从 0 开始。数字表示位数。

一个 n 位无符号整数的范围是 0..=2^n - 1。同样位宽的有符号整数使用二进制补码，范围是 -2^(n-1)..=2^(n-1) - 1。所以 u8 是 0..=255，i8 是 -128..=127。有符号范围正数一侧少一个，不是表格写歪了，而是零也占一个编码。

usize 和 isize 的位宽跟目标平台的指针宽度一致。在 64 位目标上通常是 64 位，在 32 位目标上通常是 32 位。集合长度和索引使用 usize，所以你经常会在 slice.len()、数组下标和内存大小附近遇到它。不要因为当前电脑是 64 位，就把 usize 当成永远的 u64；交叉编译到 32 位目标时，这个假设会翻车。

选整数类型时，可以先问三个问题：值可能为负吗？最大值大约是多少？外部协议是否规定了位宽？普通循环计数没有特殊约束时，默认的 i32 很好用；集合索引跟着标准库使用 usize；时间戳、文件偏移、协议字段则按它们自己的格式来。无符号类型并不自动等于“更安全”。如果余额可能出现欠款，用 u64 会把本来清楚的负数问题变成下溢问题。

无符号整数不会自动消灭负数问题

很多人第一次设计“库存数量”时会选 u32：库存不可能是负数，用无符号类型看起来天衣无缝。真正出问题的往往是扣减过程。

fn remaining(stock: u32, ordered: u32) -> Option<u32> {
    stock.checked_sub(ordered)
}
 
fn main() {
    println!("{:?}", remaining(10, 4));
    println!("{:?}", remaining(4, 10));
}

Some(6)
None

如果直接写 stock - ordered，订单超过库存时就发生下溢。debug 构建通常 panic，release 构建可能得到一个非常大的数。换成 i32 也不会自动正确：它只会让你得到 -6，至于是否允许欠货，仍要业务决定。类型负责表示范围，规则负责决定哪些范围内的值合法，这两层不能互相代替。

同样，usize 很适合索引，却不适合拿来保存“两个位置的差”然后假定结果总是非负。你写 end - start 前必须保证 end >= start。解析外部范围时，checked_sub 能把颠倒的区间变成可处理的失败；内部已经通过前置检查时，普通减法才清楚。

不同整数类型不能直接混算。下面代码会报类型不匹配：

fn main() {
    let index: usize = 3;
    let offset: u32 = 2;
 
    let next = index + offset;
    println!("{next}");
}

编译器拒绝的原因不是不知道怎么把 2 加上去，而是不知道哪边的类型才是你的约定。把 offset 转成 usize 可能在当前 64 位平台上完全可行，到了更窄的目标上却不一定；把 index 转成 u32 又可能丢掉大索引。你需要根据数据边界选择 try_from 或重新设计变量类型，而不是期待编译器随便挑一边。

范围常量比记忆更可靠

标准整数类型都有 MIN、MAX 和 BITS。需要校验或展示边界时，直接使用它们比手写魔法数字可靠。

fn main() {
    println!("u8: {}..={}, bits={}", u8::MIN, u8::MAX, u8::BITS);
    println!("i8: {}..={}, bits={}", i8::MIN, i8::MAX, i8::BITS);
}

u8: 0..=255, bits=8
i8: -128..=127, bits=8

这些常量也能让代码自己说明意图。比如协议规定长度不能超过 u16，写 value <= u16::MAX as usize 比写 value <= 65535 更容易看出边界从哪里来。不过真正执行转换时，u16::try_from(value) 还能把检查和转换合成一步，通常更不容易出现“检查了一个值，转换了另一个值”的疏漏。

除法与余数也带着类型语义

整数除法会向零截断。7 / 3 是 2，-7 / 3 是 -2。余数与被除数同号，因此 -7 % 3 是 -1。如果你在实现分页、网格坐标或数学上的模运算，别想当然地把 % 当成永远非负的“模”。需要欧几里得除法时，可以用 div_euclid 和 rem_euclid。

fn main() {
    let x = -7i32;
 
    println!("/={}  %={}", x / 3, x % 3);
    println!("div_euclid={}  rem_euclid={}", x.div_euclid(3), x.rem_euclid(3));
}

/=-2  %=-1
div_euclid=-3  rem_euclid=2

除数为零会 panic。还有一个边缘情况：有符号整数的最小值除以 -1，数学结果超过该类型的最大值，这也属于溢出。不要指望 release 构建替它悄悄回绕。

Debug 和 release 为什么可能表现不同

看下面这段代码：

fn next_attempt(current: u8) -> u8 {
    current + 1
}
 
fn main() {
    println!("{}", next_attempt(255));
}

在通常的 debug 构建中，255u8 + 1 会触发溢出检查，程序 panic。默认 release 构建通常关闭这类检查，结果按二进制补码回绕成 0。也可以通过编译选项调整溢出检查，所以真正应该记住的不是“开发环境 panic、生产环境回绕”这一句口诀，而是：普通算术表达式没有把业务想要的溢出策略写清楚。

依赖 release 回绕是危险的。测试可能因为 debug panic 及早暴露问题，也可能某些路径只在 release 数据规模下触发，最后得到一个看似正常的错误值。更稳的做法是明确选择语义。

四组方法对应四种业务态度

Rust 给整数提供了成组的方法。名字不同，是因为它们对“装不下了怎么办”给出了不同答案。

fn main() {
    let current = 250u8;
 
    println!("checked: {:?}", current.checked_add(10));
    println!("saturating: {}", current.saturating_add(10));
    println!("wrapping: {}", current.wrapping_add(10));
    println!("overflowing: {:?}", current.overflowing_add

checked: None
saturating: 255
wrapping: 4
overflowing: (4, true)

如果四种策略的差别还停留在方法名上，可以在下面的实验里调整数值和位宽，观察每种选择在越过边界时怎样变化。

checked_add 返回 Option。能算就给 Some，溢出就给 None。订单总价、配额累加、文件大小这些不能默默改值的场景，通常应该从它开始。你可以把 None 转成自己的错误，让调用方知道输入超出范围。

saturating_add 把结果夹在最小值或最大值。进度条、音量、颜色通道一类“超过上限仍按上限显示”的值很适合它。不过，如果你用它统计账务金额，超出的部分会无声消失，这种“稳定”反而掩盖错误。

wrapping_add 明确要求回绕。循环序号、哈希算法、底层协议里按固定宽度运算时，它很有用。它不是普通业务计算的兜底按钮；用了它，就应该能解释为什么回到起点正是想要的行为。

overflowing_add 同时返回回绕结果和是否溢出的标记。你既需要底层结果，又要把进位或溢出状态带到下一步时可以用它。

这四组不只包括加法，还有 checked_mul、saturating_sub、wrapping_pow 等同类方法。先确定业务行为，再挑方法，不要反过来看到哪个 API 顺手就用哪个。

乘法比加法更容易把边界藏起来。电商代码里“单价 × 数量”两边单看都合法，乘完却可能装不下。下面的写法把每一步都放在同一个受检链条里：

fn order_total(unit_price_cents: u64, quantity: u32, shipping_cents: u64) -> Result<u64, &'static str> {
    unit_price_cents
        .checked_mul(u64::from(quantity))
        .and_then(|subtotal| subtotal.checked_add(shipping_cents))
        .ok_or(

Ok(4697)
Err("订单总额超出可表示范围")

这里先把 u32 数量用 u64::from 无损扩宽，再做乘法。若反过来先在 u32 里计算，再转成 u64，溢出可能已经发生，扩宽也救不回来。这与前面“整数除法以后再转浮点已经太晚”是同一种问题：转换的位置会改变运算发生在哪个类型里。

有时你确实希望饱和。例如一个 UI 徽标最多显示 99+，内部显示计数可以写成 count.saturating_add(new_count).min(99)。但真实未读数若还要用于同步，就应该保留在更宽类型或受检结果中。不要让展示层的上限倒过来污染真实数据。

下面是一个更像实际代码的累计函数。它把空输入和溢出都变成调用方能处理的结果，不受构建模式影响：

fn checked_total(values: &[u32]) -> Result<u32, &'static str> {
    values.iter().try_fold(0u32, |total, &value| {
        total.checked_add(value).ok_or("总数超过了 u32 的范围")
    })

Ok(60)
Err("总数超过了 u32 的范围")

位运算：你操作的是每一位，不是神秘咒语

权限字段、网络协议和硬件寄存器常把多个开关压进一个整数。比如最低三位分别表示“读取、写入、执行”，一个字节就能同时保存三种状态。位运算在这种场景里比三个零散布尔值更贴近外部格式。

整数支持按位与 &、按位或 |、按位异或 ^、按位取反 !、左移 << 和右移 >>。

const READ: u8 = 0b001;
const WRITE: u8 = 0b010;
const EXECUTE: u8 = 0b100;
 
fn has_permission(flags: u8, permission: u8) -> bool {
    flags & permission != 0
}
 
fn main() {

read=true execute=false
100

& 常用来测试或保留某些位，| 用来打开某些位，^ 用来翻转位，! 会反转当前整数类型的全部位。格式化里的 :03b 表示按至少三位二进制输出，不足的前面补零。

移位需要格外小心。左值是 u8 时，有效位宽只有 8；移位量大于等于 8 属于整数溢出。它不是任你继续执行的未定义行为：当溢出检查生效时会 panic，编译器能在常量表达式里发现时也会直接报错。若移位量来自用户输入或协议字段，使用 checked_shl、checked_shr 更诚实。

fn bit_mask(bit: u32) -> Option<u8> {
    1u8.checked_shl(bit)
}
 
fn main() {
    println!("{:?}", bit_mask(3));
    println!("{:?}", bit_mask(8));
}

Some(8)
None

有符号整数右移通常会保留符号扩展，这与无符号右移补零不同。处理原始比特格式时，优先用明确位宽的无符号类型；处理真正可能为负的算术值时，再使用有符号类型。把二进制数据塞进 i32，后面每次右移都要重新确认符号，代码会很快变得难审。

位运算的问题通常不在操作符本身，而在没有写出每一位的含义。实际项目中应该给掩码命名，用常量或专门类型表达字段，不要到处散落 0x04、0x20 这种只有作者当天看得懂的数字。

浮点数：能表示很大范围，不等于能精确表示每个小数

你在结算页写下 0.1 + 0.2 == 0.3，结果却是 false。这不是 Rust 算错了，也不是 CPU 偶尔走神。十进制的 0.1 在二进制浮点格式中不能被有限位数精确表示，存进去的是附近的可表示值，运算又会继续舍入。

Rust 有 f32 和 f64 两种浮点类型，分别使用 32 位和 64 位。没有其他约束时，浮点字面量默认是 f64。f32 占用空间更少，在图形、机器学习张量或大规模数组里可能带来明显收益；f64 能保留更多有效数字，一般计算默认用它更省心。精度更高也不是无限精确，只是误差通常更小。

fn main() {
    let sum = 0.1f64 + 0.2f64;
 
    println!("{sum:.17}");
    println!("{}", sum == 0.3);
}

0.30000000000000004
false

容差要结合数值尺度

最简单的近似比较是检查绝对误差：

fn approximately_equal(a: f64, b: f64, tolerance: f64) -> bool {
    (a - b).abs() <= tolerance
}
 
fn main() {
    let sum = 0.1 + 0.2;
    println!("{}", approximately_equal(sum, 0.3, 1

true

它适合数值范围比较稳定的业务，例如传感器读数允许误差 0.001。但同一个固定容差很难同时照顾 0.0000001 和 1_000_000_000.0。数值很大时，极小的绝对容差可能严得没有意义；接近零时，只看相对误差又可能被放大。因此通用一点的比较会同时考虑绝对容差和相对容差。

fn close(a: f64, b: f64, abs_tol: f64, rel_tol: f64) -> bool {
    let diff = (a - b).abs();
    diff <= abs_tol || diff <= rel_tol * a.abs().max(b.abs())

true
true

容差是否合适要放到具体数值尺度里看。下面的实验可以同时调整目标值、计算值和两种容差，帮助你分辨“真的接近”和“只是阈值设得太宽”。

容差不是越小越严谨。它应该根据数据从哪里来、测量精度或业务允许范围确定。把 f64::EPSILON 当成所有计算的万能容差也不合适；它描述的是 1.0 附近相邻可表示值的间距，不知道你的温度计精度、坐标尺度和算法累计了多少次误差。

金额尤其值得单独说。若系统必须精确到分，可以把金额保存为整数分，或者使用明确的十进制定点方案。直接用浮点累计账款，迟早要处理舍入顺序和误差。浮点非常适合物理量、统计、图形坐标，却不是每种“带小数的值”的默认答案。

运算顺序也会改变误差

浮点加法在数学上满足交换和结合，机器表示里的结果却可能因运算顺序不同而变化。一个很大的数加上一个很小的数，小数部分可能落在当前精度无法分辨的间隔里，直接被舍掉。

fn main() {
    let positive = 1e16f64;
    let negative = -1e16f64;
    let one = 1.0f64;
 
    let left = (positive + negative) + one;
    let right = positive + (negative + one);
 
    println!

left=1, right=0

左边先让两个大数抵消，再加 1，所以保住了结果；右边先把 1 加到巨大负数上，这个单位小到无法落进当前间隔，先被舍掉了。更一般地说，大量浮点值求和时，先加大数还是先加小数、正负数怎样抵消，都会影响累计误差。统计程序不能只看公式在纸面上等价，还要用有代表性的数据做误差测试。对精度要求高的聚合可能需要更合适的求和算法，而不是简单把类型从 f32 换成 f64 就宣布解决。

浮点还有 round、floor、ceil、trunc 等取整方法。它们返回的仍是浮点值，区别在于方向：floor 向负无穷，ceil 向正无穷，trunc 向零，round 按最近整数并处理正好居中的情况。负数场景最能暴露混淆。

fn main() {
    let value = -3.7f64;
 
    println!(
        "floor={} ceil={} trunc={} round={}",
        value.floor(),
        value.ceil(),
        value.trunc(),
        value.round()
    );
}

floor=-4 ceil=-3 trunc=-3 round=-4

分页、坐标网格和税费规则对取整方向可能有不同要求。不要把 as i32 当成通用取整，因为它固定向零截断，而且还把范围外值和 NaN 按自己的规则映射。先选择业务需要的取整方式，再检查范围，再转换成整数，读起来也更清楚。

f32 与 f64 的选择不只看小数位数

f32 大约能保留 6 到 7 位十进制有效数字，f64 大约能保留 15 到 16 位。这里说的是有效数字，不是小数点后固定几位。12_345_678.0f32 已经可能无法区分相邻整数，而 0.0000012345678f32 又能保留一部分小数。数值的量级会影响相邻可表示值之间的间隔。

大批量图像像素、神经网络参数和 GPU 数据常选择 f32，因为内存、带宽和硬件吞吐都可能比额外精度更重要。财务分析、科学计算的中间值或普通业务比例通常更偏向 f64。如果数据最终来自只有三位精度的传感器，盲目使用 f64 也不会创造额外真实信息；它只是减少后续计算再引入的舍入。

接口边界还要注意类型来回转换。一个值从 f64 缩成 f32 后丢掉的精度，再转回 f64 不会恢复。数据库列、序列化格式和外部 API 如果固定使用某种精度，应用内部的选择要把这条链路一起考虑，而不是只看某一行变量声明。

NaN 会打破你对比较的直觉

浮点还可以表示正无穷、负无穷和 NaN。NaN 的意思是某次计算没有得到普通数值，例如 0.0 / 0.0。它最反直觉的地方是：NaN 不等于任何值，包括它自己；小于和大于比较也都不会给出正常的全序关系。

fn main() {
    let value = 0.0f64 / 0.0;
 
    println!("is_nan={}", value.is_nan());
    println!("equal_to_self={}", value == value);
    println!("partial_cmp={:?}", value.partial_cmp(&1.0));
}

is_nan=true
equal_to_self=false
partial_cmp=None

所以检查 NaN 要用 is_nan()，不要写 value == f64::NAN。接收外部浮点输入时，还可以用 is_finite() 排除 NaN 和正负无穷。否则一个异常值进入排序、求最值或聚合后，错误可能离输入点很远才出现。

如果业务确实需要把所有浮点值连同 NaN 一起排序，可以明确使用 total_cmp 建立全序。若业务认为 NaN 根本不合法，更好的做法是在边界处拒绝它，而不是让排序规则替你掩盖脏数据。

fn main() {
    let mut values = [3.0, f64::NAN, -0.0, 0.0, f64::INFINITY];
    values.sort_by(f64::total_cmp);
 
    println!("{:?}", values);
}

这里不固定展示文本输出，因为不同 NaN 的具体比特形式没有必要成为业务约定。关键点是 total_cmp 能给出稳定的排序关系，而普通浮点比较只有偏序。

这也是 f64 不能直接像普通整数那样承担所有“可排序键”职责的原因。标准比较必须面对 NaN，所以浮点只提供偏序。若你想把浮点当作有序映射的键或要求去重规则稳定，需要先定义域：输入是否保证有限，正零和负零是否视为相同，多个 NaN 如何处理。把这些规则包进专门类型，比在每次排序时临时写一个闭包更可靠。

正无穷和负无穷也不一定是错误。某些算法把它们当作自然的初始哨兵值；但来自用户输入的无穷温度通常就是坏数据。is_nan()、is_infinite() 和 is_finite() 没有谁永远更正确，取决于这个字段允许的值域。基本类型告诉你机器能表示什么，领域规则告诉你程序愿意接受什么。

布尔值：条件必须明确说真或假

从 C、JavaScript 或 Python 转来时，你可能会写出这样的判断：

fn main() {
    let retry_count = 3;
 
    if retry_count {
        println!("继续重试");
    }
}

编译器会指出 if 需要 bool，却拿到了整数。Rust 没有“零是假、非零是真”这种隐式规则。你必须把意思写清楚：是还有重试次数，还是刚好重试了三次？

fn main() {
    let retry_count = 3;
    let should_retry = retry_count > 0;
 
    if should_retry {
        println!("继续重试");
    }
}

bool 只有 true 和 false。它支持逻辑非 !、逻辑与 &&、逻辑或 ||。&& 和 || 会短路：左侧已经能决定结果时，右侧不会执行。这常用来先检查前置条件，再执行可能有成本或有边界要求的判断。

fn main() {
    let name = "小虎";
    let valid = !name.is_empty() && name.len() <= 12;
 
    println!("{valid}");
}

if 本身是表达式，可以产生值，但两个分支必须得到兼容的类型。

fn main() {
    let score = 86;
    let level = if score >= 60 { "通过" } else { "未通过" };
 
    println!("{level}");
}

如果一个分支返回字符串，另一个分支返回整数，编译器会拒绝，因为接收变量在运行前必须有确定类型。它不是故意限制灵活性，而是在阻止“这个变量有时是文字、有时是数字”一路传到更远的代码里。

char：一个 Unicode 标量值，不一定是你眼中的一个字

Rust 的 char 用单引号，例如 'A'、'中'、'🦀'。它固定占 4 字节，保存一个 Unicode 标量值。这句话里最容易被忽略的是“标量值”：它跟用户看到的一个完整字符并不总是一一对应。

fn main() {
    let latin = 'A';
    let chinese = '中';
    let crab = '🦀';
 
    println!("{} {} {}", latin.len_utf8(), chinese.len_utf8(), crab.len_utf8());
    println!("U+{:04X}", crab as u32);
}

1 3 4
U+1F980

char 自身总是 4 字节，但同一个值编码进 UTF-8 字符串后会占 1 到 4 个字节。ASCII 字母 A 占 1 字节，常见中文通常占 3 字节，很多 emoji 占 4 字节。这正是后面 String::len() 返回字节数，而不是 char 数量的原因。

更麻烦的是，人眼看到的一个字形可能由多个 Unicode 标量值组成。例如带重音符号的字母既可能是一个预组合标量，也可能是普通字母后面跟一个组合符号。某些 emoji 也由多个标量通过连接符组合。于是：

fn main() {
    let precomposed = "é";
    let combined = "e\u{301}";
 
    println!("{} {}", precomposed.chars().count(), combined.chars().count());
    println!("{}", precomposed == combined);
}

1 2
false

它们看起来接近，底层序列却不同。标准库的 .chars() 按 Unicode 标量值遍历，不按用户感知的字形簇遍历。做语法分析、检查 ASCII 标记或逐标量转换时，.chars() 很合适；做“昵称最多 12 个可见字符”、移动文本光标或删除一个 emoji 时，需要专门的 Unicode 分段能力，不能用 .chars().count() 假装问题已经解决。

从整数得到字符也要看范围。u8 as char 总能得到对应标量值；一般的 u32 可能落在无效区域，应该用 char::from_u32，它返回 Option<char>。

fn main() {
    println!("{:?}", char::from_u32(0x1F980));
    println!("{:?}", char::from_u32(0x11_0000));
}

Some('🦀')
None

编译器在这里像一个严格的文字编辑：它不允许你把任意 32 位整数冒充成合法 char。这种限制会让底层解析多写一步，却保证后续字符串代码可以相信其中的标量值有效。

字符转大小写可能产生不止一个标量值

ASCII 里，一个小写字母通常对应一个大写字母，所以你可能猜 to_uppercase() 会返回另一个 char。Unicode 没有这么整齐，有些字符的大写形式需要多个标量值。因此 char::to_uppercase() 返回迭代器，而不是单个 char。

fn main() {
    let upper: String = 'ß'.to_uppercase().collect();
    println!("{upper}");
}

SS

这类细节会影响“大小写转换后长度不变”的假设。登录名、搜索和不区分大小写比较还会牵涉语言环境与规范化，不应该靠逐个 char 手写一套简单映射。标准库提供的 Unicode 操作已经比 ASCII 规则丰富，但完整的自然语言文本处理仍然需要更明确的产品规则。

字符字面量还支持转义：'\n' 是换行，'\t' 是制表，'\'' 是单引号，'\u{1F980}' 是螃蟹 emoji。转义改变的是源码写法，不改变 char 的本质。解析用户输入里的六个字符 \u{41} 时，它不会自动变成 'A'；那是你的输入格式是否定义转义语法的问题。

字符串：先分清拥有数据，还是看一段数据

Rust 字符串是新手最容易产生挫败感的地方。你只是想把名字传进函数，却同时看到了 str、&str、String；接着想拿“第一个字符”，编译器又拒绝 name[0]。先别急着把它归因于所有权太复杂。这里其实叠着两个问题：谁拥有缓冲区，以及 UTF-8 的位置到底按什么计算。

str、&str 与 String 各自是什么

str 表示一段有效的 UTF-8 字节序列。它是动态大小类型，编译时不一定知道具体有多少字节，所以你几乎不会单独持有一个裸 str，通常通过 &str 使用它。

&str 是对某段字符串数据的借用视图，可以直觉地理解成“起始位置 + 字节长度”。字符串字面量的类型就是 &'static str，数据随程序存在。一个 String 的局部切片也可以是 &str，但有效时间受原 String 约束。

String 拥有一块堆上的、可增长的 UTF-8 缓冲区。它记录指针、当前字节长度和容量。离开作用域时，它负责释放缓冲区。String 可以修改和追加；&str 是否能修改取决于借用类型，但普通共享的 &str 不能改。

fn greet(name: &str) -> String {
    format!("你好，{name}！")
}
 
fn main() {
    let literal = "Rust";                  // &str
    let owned = String::from("小虎");      // String
    let view: &str = owned.as_str

你好，Rust！
你好，小虎！

只读取文字的函数参数通常优先接收 &str。这样字符串字面量和 String 的借用都能传进来。函数需要保存文字、跨出调用者的借用范围，或者要取得并修改缓冲区时，再接收或创建 String。返回新拼出来的文字时返回 String 很自然，因为新缓冲区需要有人拥有。

从 &str 变成 String 可以用 to_owned()、to_string() 或 String::from()，通常需要分配并复制字节。从 String 借成 &str 不复制数据。这个成本差异值得记住：函数只是看一眼名字，却要求调用者交一个新 String，往往会制造没必要的分配。

借用视图还有一个重要约束：原 String 的缓冲区一旦修改，旧切片可能失效。追加内容时缓冲区可能重新分配；即使没有重新分配，插入和删除也可能移动字节。Rust 会阻止你在共享切片仍被使用时修改原字符串。

fn main() {
    let mut message = String::from("错误：磁盘已满");
    let category = &message[..6];
 
    message.push_str("，请清理空间");
    println!("{category}");
}

这段代码会遭到借用检查器拒绝。category 仍指向 message 的一部分，而 push_str 需要可变借用并可能让旧位置失效。解决方式通常不是复制所有东西，而是缩短共享借用的使用范围：

fn main() {
    let mut message = String::from("错误：磁盘已满");
 
    {
        let category = &message[..6];
        println!("{category}");
    }
 
    message.push_str("，请清理空间");
    println!("{message}");
}

错误
错误：磁盘已满，请清理空间

这里 0..6 是两个中文标量的字节范围，对应“错误”。为了让输出包含全角冒号，需要切到第 9 字节，因此上面的示例其实暴露了一个很好的复核习惯：别靠肉眼猜中文边界。更清楚的写法是先通过文本查找得到位置。

fn main() {
    let mut message = String::from("错误：磁盘已满");
 
    if let Some(end) = message.find('：') {
        let category = &message[..end];
        println!("{category}");
    }
 
    message.push_str("，请清理空间");

错误
错误：磁盘已满，请清理空间

我们故意保留了前一个“看起来合理却切错语义”的例子，因为 UTF-8 的痛点往往不是程序立刻崩，而是范围合法、结果却不是你以为的那一段。编译器能守住编码边界，守不住“冒号应不应该包含在分类名里”这种产品含义。

UTF-8 让“第几个字符”不再是一个简单问题

看下面这段代码：

fn main() {
    let name = String::from("小虎");
    let first = name[0];
    println!("{first}");
}

它不会通过编译。原因不只是 Rust 没实现下标，而是 0 的单位不清楚。如果它表示第 0 个字节，你拿到的是汉字编码的第一段，单独不是有效字符；如果表示第 0 个 char，就需要从开头扫描 UTF-8；如果表示用户眼中的第 0 个字形，规则还要更复杂。Rust 拒绝用一个看似常数时间的下标掩盖这些差异。

len() 返回字节数：

fn main() {
    let text = "A小🦀";
 
    println!("bytes={}", text.len());
    println!("chars={}", text.chars().count());
    println!("{:?}", text.as_bytes());
}

bytes=8
chars=3
[65, 229, 176, 143, 240, 159, 166, 128]

需要原始字节时用 .bytes() 或 .as_bytes()；需要 Unicode 标量值时用 .chars()；同时需要每个标量起始字节位置时用 .char_indices()。选哪个取决于你在处理协议、文本标量，还是用户可见字形。

字符串切片的范围是字节范围

字符串可以做范围切片，但起止位置必须同时满足三个条件：没有越过长度、起点不大于终点、两端都落在 UTF-8 标量边界上。

fn main() {
    let text = "你好Rust";
    let chinese = &text[0..6];
    let rust = &text[6..10];
 
    println!("{chinese} {rust}");
}

你好 Rust

两个汉字各占 3 字节，所以 0..6 刚好完整覆盖“你好”。若写成 0..5，索引语法会在运行时 panic，因为结束位置切进了“好”的编码中间。来自外部输入的范围不要直接放进 text[start..end]，用 get 可以把非法范围变成 None。

fn preview(text: &str, end: usize) -> Option<&str> {
    text.get(..end)
}
 
fn main() {
    let text = "你好Rust";
 
    println!("{:?}", preview(text, 6));
    println!("{:?}", 

Some("你好")
None

is_char_boundary(index) 可以先检查某个字节位置是否是边界，char_indices() 则适合在遍历时获得合法位置。这里的“char 边界”是 Unicode 标量值边界，不等于完整字形边界。

字节位置和字符边界很难只靠肉眼稳定判断。下面的边界图可以逐字查看 UTF-8 编码，并直接比较合法切片与切进编码中间的范围。

修改字符串也必须尊重边界

String 支持 push(char)、push_str(&str)、insert、insert_str 等操作。插入位置同样按字节计算，而且必须落在 UTF-8 边界。追加到末尾通常最省心；在中间频繁插入则可能移动后续全部字节，长文本编辑器不会只靠一个 String 硬扛所有操作。

fn main() {
    let mut message = String::with_capacity(32);
    message.push_str("你好");
    message.push('，');
    message.push_str("Rust");
    message.insert_str(0, "提示：");
 
    println!("{message}");

capacity 是当前缓冲区能容纳的字节数，至少不小于 len，但增长策略不是业务接口的一部分，不要断言它必须等于某个固定值。大致知道最终大小时，with_capacity 能减少追加过程中的重新分配；完全不知道时，先用 String::new() 也没问题，别为了猜容量把简单代码写复杂。

格式化多段内容时，format! 会生成新的 String，可读性通常比一串 + 更好。String + &str 也能拼接，但它会取得左侧 String 的所有权，这常让刚学所有权的人再次撞上“值已移动”。如果你还要使用原字符串，优先考虑 format! 或在可变 String 上 push_str。

外部字节进入文本世界以前要先过一道门

文件、网络和设备给你的往往不是 String，而是一串 u8。Rust 保证 str 和 String 内部始终是有效 UTF-8，因此任意 Vec<u8> 不能直接改名成 String。这个限制有点像门卫：字节在外面可以是什么格式，进入字符串 API 以后就必须满足 UTF-8 约定。

fn decode_name(bytes: Vec<u8>) -> Result<String, String> {
    String::from_utf8(bytes).map_err(|error| {
        format!("名称不是合法 UTF-8，首个问题位置：{}", error.utf8_error().valid_up_to())
    })
}
 
fn main() {
    println!

Ok("小虎")
Err("名称不是合法 UTF-8，首个问题位置：4")

String::from_utf8 会取得这个 Vec<u8> 的所有权。验证成功后通常不需要重新复制缓冲区；失败时错误值里仍能取回原始字节。如果你只是暂时查看借来的 &[u8]，可以用 std::str::from_utf8，成功得到借来的 &str。

日志系统有时宁愿尽量展示，也不想因为一个坏字节丢掉整行。这时可以选择损失性解码，把非法片段替换成 �。这个行为必须是明确选择，因为替换以后原始内容已经改变。

fn main() {
    let raw = [b'R', b'u', b's', b't', 0xFF];
    let text = String::from_utf8_lossy(&raw);
 
    println!("{text}");
}

Rust�

展示日志可以容忍替换，用户名比较、数字签名、协议字段通常不能。更不能遇到解码失败就使用不检查 UTF-8 的 unsafe 构造函数。那些函数的前提是调用者已经通过别的方式证明字节有效，不是绕开错误处理的快捷通道。错误字节混进 String 会破坏标准库赖以工作的基本约束，代价远大于多写一个 Result 分支。

还要区分“不是 UTF-8”和“不是文本”。图片、压缩包、加密密文本来就是二进制，应该继续使用 &[u8]、Vec<u8> 或专门格式，不需要强行转成字符串。看到字节不等于立刻解码，先问协议说它是什么。

文本来自操作系统路径时也别擅自假定一定是 UTF-8。Rust 为路径和操作系统字符串提供了专门类型，因为某些平台允许无法表示成普通 String 的路径。把这类值强行损失性转换适合界面展示，却不适合再拿结果去精确打开原文件。基本类型的边界在这里非常实际：选择 String，就等于声明“这段数据是有效 UTF-8 文本”。

数组与切片：一个拥有固定长度，一个提供连续视图

你写了一个函数，只想计算几个温度的平均值，于是参数写成 [f64; 3]。后来调用方要传一周七天的数据，你才发现函数签名把长度也锁死了。这不是数组不好用，而是你把“必须恰好三个值”和“接受任意一段连续数据”混成了同一件事。

数组长度是类型的一部分

数组类型写作 [T; N]，其中 T 是元素类型，N 是编译期确定的长度。[i32; 3] 和 [i32; 4] 是不同类型。数组拥有元素，长度固定，适合月份、RGB 通道、固定协议头、坐标矩阵这类尺寸本身有意义的数据。

fn main() {
    let rgb: [u8; 3] = [32, 128, 240];
    let zeros = [0u16; 5];
 
    println!("{:?}", rgb);
    println!("{:?}", zeros);
}

[32, 128, 240]
[0, 0, 0, 0, 0]

[value; N] 表示重复初始化。对非 Copy 类型要注意：它不是把任意复杂对象自动深复制 N 次。若每个元素都要独立构造，可以使用 std::array::from_fn。

数组下标是 usize。用 array[index] 访问越界会 panic。索引来自外部数据时，get(index) 返回 Option<&T>，能让你明确处理缺失。

fn main() {
    let ports = [80u16, 443, 8080];
 
match ports.get(3) {
        Some(port) => println!("port={port}"),
        None => println!("没有这个端口位置"),
    }
}

数组整体赋值和传参的成本要看元素类型与长度。小型 Copy 数组按值传入会复制全部元素；包含 String 的数组按值传入则会移动整个数组的所有权。函数只需要读取时，收 &[T] 通常更通用，也避免调用者失去所有权。尺寸很小且长度就是协议的一部分时，按值接收数组又可能更直接。

fn checksum(bytes: &[u8]) -> u8 {
    bytes.iter().fold(0u8, |sum, &byte| sum.wrapping_add(byte))
}
 
fn main() {
    let header = [0x10, 0x20, 0x30, 

160
[16, 32, 48, 64]

这里校验和按协议明确采用 8 位回绕，所以 wrapping_add 比普通 + 更能说明意图。函数参数是切片，调用以后数组仍然可用。

切片不拥有元素，只描述一段连续区域

切片类型是 [T]，通常通过共享借用 &[T] 或可变借用 &mut [T] 使用。一个切片可以理解成“指向首元素的位置 + 元素数量”。它不知道底层最初来自数组、Vec<T> 还是别的连续存储，这正是它适合作为函数参数的原因。

fn average(values: &[f64]) -> Option<f64> {
    if values.is_empty() {
        return None;
    }
 
    Some(values.iter().sum::<f64>() / values.len() as f64)
}
 
fn

Some(18.642857142857142)
Some(20.166666666666668)
None

函数收 &[f64]，既能接整个数组，也能接其中一段。空切片是否有平均值由我们明确返回 None，没有偷偷除以零得到 NaN。

数组拥有元素，切片只描述连续视图；共享与可变借用又会改变允许的操作。你可以在下面的工作台里拆分范围，观察多个视图是否重叠以及修改会落到哪一段底层数据。

可变切片允许修改底层元素，但仍不拥有它们，也不能改变长度。

fn clamp_scores(scores: &mut [i32]) {
    for score in scores {
        *score = (*score).clamp(0, 100);
    }
}
 
fn main() {
    let mut scores = [-3, 86, 120];
    clamp_scores

[0, 86, 100]

共享切片可以同时有多个，因为大家都只读；可变切片在同一段数据上必须独占。这个规则会在你想同时修改两个元素时出现。直觉上，索引 0 和 2 显然不是同一个位置，但如果两个索引来自运行时，借用检查器必须防止它们碰巧相等。

安全做法是先按不重叠范围拆开，或者使用能检查索引是否重复的专用方法。已知中点时，split_at_mut 最清楚：

fn swap_halves(values: &mut [i32], mid: usize) {
    let (left, right) = values.split_at_mut(mid);
 
    for (a, b) in left.iter_mut().zip(right.iter_mut()) {
        std::mem::swap(a, b);
    }
}
 
fn main() {

[4, 5, 6, 1, 2, 3]

若 mid 大于长度，split_at_mut 会 panic。边界来自外部时先检查，或者使用返回可选结果的受检形式。即使每一段内部访问都合法，“从哪里切开”仍然是调用方需要守住的条件。

用切片方法表达“怎么看这段数据”

windows(n) 返回重叠窗口，适合相邻差值、移动检查；chunks(n) 从头按块分组，最后一块可能不足；chunks_exact(n) 只产生完整块，并能单独取出余数。

fn main() {
    let data = [10, 12, 15, 14, 20];
 
    let changes: Vec<i32> = data.windows(2)
        .map(|pair| pair[1] - pair[0])
        .

changes=[2, 3, -1, 6]
chunk=[10, 12]
chunk=[15, 14]
chunk=[20]

分块大小不能是零，否则这些方法会 panic。若大小来自配置，先验证再调用。切片范围同样可以用 get(range) 避免越界 panic。

另一个很实用的方法是 split_at_mut：它把一个可变切片拆成两段互不重叠的可变切片。你手写 &mut values[..mid] 和 &mut values[mid..] 时，借用检查器可能无法从两个独立表达式确认它们不重叠；专用方法把这个事实表达得更清楚。编译器在这里不是不相信你的数学，而是需要一个能在类型规则里验证的边界。

数组和切片的选择可以压缩成一句话：长度参与正确性时用数组表达，长度只属于运行时数据时让函数看切片。动态增长则是另一种需求，通常交给 Vec<T>。不要因为三者都能用下标就忽略它们对所有权、长度和分配方式的不同承诺。

元组：适合短小的临时组合，不适合藏住含义

函数需要同时返回最小值和最大值时，专门建一个结构体可能显得重；返回两个互相关联的值又很自然。元组就是这种短小组合的工具。它长度固定，但各位置可以是不同类型。

fn bounds(values: &[i32]) -> Option<(i32, i32)> {
    let first = *values.first()?;
    let mut min = first;
    let mut max = first;
 
    for &value in &values[1..] {

min=-2, max=9

可以通过模式解构取出各位置，也可以用 .0、.1 访问。下标必须是编译期已知的位置，不能拿运行时变量写 tuple[index]，因为不同位置可能有不同类型。

单元素元组必须带逗号：(42,) 是一个长度为 1 的元组，(42) 只是加了括号的整数。空元组 () 叫单元类型，它表示“没有有意义的返回值”。没有显式返回值的函数，返回类型就是 ()。

fn log_ready() {
    println!("ready");
}
 
fn main() {
    let one = (42,);
    let unit: () = log_ready();
 
    println!("{} {:?}", one.0, unit);
}

ready
42 ()

元组的权衡很直接：写起来轻，位置含义却容易丢。(String, u16, bool) 在十行内也许清楚，跨模块传递后，.1 究竟是端口还是重试次数就要靠记忆。字段会增长、含义需要命名或要形成公开接口时，换成结构体通常更合适。元组适合临时打包，不该成为逃避建模的暗袋子。

类型转换：先问会不会丢信息

Rust 不会随意在数字类型之间做隐式转换。u8 明明肯定能放进 u32，你仍然不能直接把两者相加。刚开始会觉得麻烦，但它迫使代码说明“转换发生在这里”，也阻止有符号、无符号和不同位宽在复杂表达式里悄悄改变结果。

转换可以先分成两类：一定能完整完成的，以及可能失败或丢信息的。From、Into 适合前者；TryFrom、TryInto 适合后者。as 更接近按语言规定执行数值转换，简短但不替你报告信息损失。

as 会照规则转换，不会替你报警

大整数转成小整数时，as 保留目标位宽能容纳的低位，高位被截掉。

fn main() {
    let value = 300u16;
    let narrowed = value as u8;
 
    println!("{narrowed}");
}

44

300 的十六进制是 0x012C，变成 8 位后只剩 0x2C，也就是 44。这不是溢出 panic，也不会返回错误。若这正是你在拆低 8 位，as 很合适；若你在转换用户年龄，它就是安静的数据损坏。

同位宽有符号与无符号之间转换，会按二进制补码解释相同的位模式。因此 -1i8 as u8 是 255。宽整数转窄整数先截断，再按目标类型解释。这样的规则稳定明确，但读代码的人很难只凭一眼判断值是否在范围内，所以业务边界不要滥用 as。

浮点转整数时会向零截掉小数部分。超出目标范围的有限值会夹到目标整数的边界，NaN 会得到 0。这些规则避免了未定义结果，却不表示转换符合你的业务。比如订单数量 3.9 变成 3，可能应该先拒绝非整数输入，而不是默默截断。

fn main() {
    println!("{}", 3.9f64 as i32);
    println!("{}", (-3.9f64) as i32);
    println!("{}", f64::NAN as i32);
    println!("{}", 1e100f64 as i32);

3
-3
0
2147483647

整数转浮点也可能丢精度。f64 的范围很大，却不能逐个精确区分全部 u64。位数很大的 ID 一旦转成浮点再转回来，可能已经变成邻近整数。不要为了塞进 JSON、表格或图表就假定大整数能无损经过浮点。

bool as u8 可以得到 0 或 1，char as u32 可以得到对应码点；反方向并不对称。Rust 不允许 1u8 as bool，因为“哪些整数算真”需要业务自己表达。任意 u32 也不能直接 as char，因为有些码点不是合法 Unicode 标量值。

From 与 Into 表达不会失败的转换

当目标类型能完整表示源值，而且转换有清楚、唯一、不会失败的含义时，标准库通常提供 From。

fn main() {
    let small = 200u8;
    let wide = u16::from(small);
 
    let name_slice = "小虎";
    let name = String::from(name_slice);
 
    println!("{wide} {name}");
}

实现 From<T> for U 后，会自动得到对应的 Into<U> for T。所以同一个转换也可以写成：

fn main() {
    let small = 200u8;
    let wide: u16 = small.into();
 
    println!("{wide}");
}

From 把目标类型写在前面，阅读具体转换时很清楚；Into 在泛型参数和方法链附近更顺手，但经常需要上下文帮它确定目标类型。两者不是“安全版强转”的两个独立机制，而是一对互相对应的接口。

不会失败也不等于没有成本。String::from(&str) 在语义上一定成功，但通常要分配并复制字节。From 保证的是转换结果，不保证零分配或零开销。

TryFrom 与 TryInto 把失败交还给调用方

u16 转 u8 可能成功，也可能装不下。与其用 as 截断，业务数据通常应该使用 TryFrom 或 TryInto，得到 Result。

use std::convert::TryFrom;
 
fn main() {
    let ok = u8::try_from(200u16);
    let too_large = u8::try_from(300u16);
 
    println!("{:?}", ok);
    println!("{:?}", too_large.is_err());
}

Ok(200)
true

从值这一侧写，可以用 try_into()：

use std::convert::TryInto;
 
fn packet_length(raw: u32) -> Result<u16, &'static str> {
    raw.try_into().map_err(|_| "数据包长度超过协议上限")
}
 
fn main() {
    println!("{:?}", 

Ok(4096)
Err("数据包长度超过协议上限")

写自己的类型时，通常实现 From 或 TryFrom，对应的 Into 或 TryInto 会自动获得。判断用哪个的标准也很朴素：如果转换可能因为输入内容、范围或业务约束失败，就别把失败藏起来。

自定义转换可以把校验集中在类型入口

假设重试次数在底层存成 u8，业务却只允许 0..=10。单用 u8 表达不了更窄的限制，如果每个调用点都手写判断，很快会有人漏掉。可以定义一个专门类型，并让 TryFrom<u8> 成为创建入口。

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
struct RetryCount(u8);
 
impl TryFrom<u8> for RetryCount {
    type Error = &'static str;
 
    fn try_from(value: u8) -> Result<Self, 

RetryCount(3) 3
Err("重试次数不能超过 10")

从 u8 进入 RetryCount 可能失败，所以用 TryFrom；从已经验证过的 RetryCount 取回 u8 一定成功，所以用 From。方向不同，失败语义也不同。这样做以后，只要内部字段不被随意公开，拿到 RetryCount 的代码就可以相信范围已经检查过。

实现转换时别把“方便”误当成“不会失败”。例如文本到重试次数既可能不是数字，也可能数字超出 u8，还可能超出业务上限。你可以专门实现文本解析，或者在配置层分步骤处理，让不同错误有清楚提示。硬把所有问题塞进一个模糊的“转换失败”，调用者就很难告诉用户究竟哪里不对。

泛型参数里为什么常看到 Into 和 TryInto

具体代码知道目标类型时，U::from(value) 通常最直观。库函数希望接收多种能转换成目标类型的输入时，常把 Into<U> 写成参数约束。

fn labeled<T: Into<String>>(value: T) -> String {
    let value = value.into();
    format!("标签：{value}")
}
 
fn main() {
    println!("{}", labeled("稳定"));
    println!("{}", labeled

标签：稳定
标签：灰度

这个接口同时接受 &str 和 String，最终都取得一个 String。代价也要看清：传 String 时可以移动现有缓冲区，传 &str 时需要创建拥有的数据。若函数只读一下标签，参数写 &str 会更便宜、更直接；只有函数确实要拥有结果时，Into<String> 才是合适的灵活性。

可能失败的泛型转换同理可以约束 TryInto<U>。错误类型会进入函数签名，设计会复杂一些，但调用方能使用自己已有的可转换类型。公开库接口需要这种扩展性时很有价值；应用内部只有一种输入时，直接写具体类型往往更易读。泛型不是越多越通用越好，接口的实际调用方式才是判断标准。

先转换还是先运算，结果可能完全不同

下面两段看起来都在计算“字节数乘以份数并转成 u16”，安全性却不同：

fn total_bytes(bytes: u8, copies: u8) -> Option<u16> {
    let wide_first = u16::from(bytes) * u16::from(copies);
    Some(wide_first)
}
 
fn main() {
    println!("{:?}", total_bytes(200, 2));
}

Some(400)

如果先在 u8 中写 bytes * copies，200 * 2 已经越界，后面再 as u16 或 u16::from 都无法修复。反过来，缩窄转换应尽量放在最后，并用 try_from 确认最终结果装得下。这个顺序习惯能避免一大类“每个输入都合法，中间结果却溢出”的错误。

字符串解析数字使用的是 parse()，背后是另一套专门处理文本解析的接口。它同样返回 Result，理念相同：文本不保证是合法数字，调用方必须决定出错怎么办。不要因为 unwrap() 写起来短，就把配置文件、用户输入和网络数据的错误变成整个进程的 panic。

把这些类型放进同一个真实入口

单独看每种类型容易觉得规则零散。我们用一个小场景把它们串起来：程序从文本配置中读取端口、重试次数和负载阈值，再解析一行逗号分隔的标签。外部输入最擅长制造边界问题，所以这里不使用 unwrap()。

#[derive(Debug)]
struct Config<'a> {
    port: u16,
    retries: u8,
    threshold: f64,
    labels: [&'a str; 3],
}
 
fn parse_finite(value: &str, field: &str) ->

port=8080, retries=3, threshold=0.85, labels=["稳定", "灰度", "中文"]

这段代码没有什么炫技的地方，恰好说明基本类型真正的价值：u16 把端口上限带进解析，u8 把重试次数限制在更小范围，is_finite 拦住浮点特殊值，范围表达式检查业务阈值，&str 让标签借用原始输入而不复制，Vec<&str> 暂存动态分割结果，try_into 再确认它恰好能组成三元素数组。

编译器只能保证类型规则，不知道阈值必须在 0.0..=1.0，也不知道标签必须三项。业务检查仍然要你写。反过来，一旦你把这些约束写清楚，后续代码拿到 Config 时就不必反复猜测数据是否合法。这是 Rust 类型系统最实在的合作方式：它负责守住你表达出来的规则，没表达的部分不会凭空替你补齐。

成功样例只能证明一条路，边界样例才说明规则真的生效

真实项目最容易漏测的是“语法合法但业务非法”。"NaN" 能成功解析成 f64，却不该成为负载阈值；"1.2" 也是正常浮点数，却超出比例范围。端口 "70000" 连 u16 都装不下，应该在解析阶段失败。标签则可能每一项文字都合法，但数量不对。

可以把这些输入逐个喂给前面的函数：

fn show_error(port: &str, retries: &str, threshold: &str, labels: &str) {
    match parse_config(port, retries, threshold, labels) {
        Ok(_) => println!("配置有效"),
        Err(error) => println!("{error}"),
    }
}
 
fn main() {
    show_error

保留前面的 Config、parse_finite、parse_config 定义，再用这里的 show_error 和 main 替换前一个 main，输出为：

port 必须是 0 到 65535 的整数
retries 必须是 0 到 255 的整数
threshold 不能是 NaN 或无穷
threshold 必须在 0.0 到 1.0 之间
labels 必须恰好有三项

错误发生的顺序也很重要。parse_config 先检查端口，再检查重试次数，然后检查阈值和标签；一次调用只返回最先遇到的问题。这种方式实现简单，适合命令启动时立即失败。表单界面如果希望一次显示全部字段错误，就需要收集多个错误，而不是用 ? 遇到第一个就返回。类型没有替你决定交互方式，它只是让每个失败点有明确结果。

还可以看到，存储类型的范围与业务范围不一定相同。重试次数解析成 u8 只保证 0..=255，如果产品规则只允许最多 10 次，还应像前面的 RetryCount 那样加一层领域类型，或者在配置构造时继续校验。端口 0 能装进 u16，但某个服务是否允许绑定端口 0，也要按具体用途判断。

代码评审时可以沿着值的旅程检查

面对一段类型很多的 Rust 代码，不必从头背 API。顺着一个值走，通常能把问题拆成四步：

这套顺序不会消灭所有 bug，但能把“Rust 类型好多”变成几件可检查的事。尤其在编译器给出类型不匹配时，先别急着加一个 as 让红线消失。顺着值的旅程问一遍，常常会发现真正的问题是前面选错了类型，或者后面接口表达得不够准确。

还有一个很朴素的信号：如果同一个值在函数里连续转换三四次，先停下来看看接口是否在使用不同的单位或不同的领域概念。索引、字节数、字符数都可能碰巧是 usize，却不能因此随意相加；金额分和普通计数都可能是 u64，含义仍然完全不同。基础类型解决机器表示，变量名、结构体和领域类型负责保留业务含义。两边配合，才不会出现“所有类型都能编译，结果却算错单位”的问题。

编译错误也应该尽量在根源处修。函数真正需要切片，就把参数从固定数组改成 &[T]；输入可能越界，就让转换返回 Result；数据本来是字节，就别为了调用字符串方法提前做损失性解码。一个局部强转有时能让当前行通过，却会把不一致推到下一行。严格的搭档最有价值的地方，往往正是它不肯接受这个临时糊弄。

练习：在边界处做出明确选择

先别急着看答案。每道题都对应这一章里一个常见的误判。

动手题：修复一个会随构建模式变化的计数器

下面的函数接收当前失败次数和本次新增次数。要求它在超过 u16 上限时返回错误，不能 panic，不能回绕，也不能静默停在最大值。

fn add_failures(current: u16, added: u16) -> Result<u16, &'static str> {
    // 在这里完成
    todo!()
}

fn add_failures(current: u16, added: u16) -> Result<u16, &'static str> {
    current.checked_add(added).ok_or("失败次数超过 u16 上限")
}
 
fn main() {
    assert_eq!(add_failures(10, 5), Ok(

动手题：安全截取不超过指定字节数的前缀

实现一个函数，返回字符串中不超过 max_bytes 的最长合法 UTF-8 前缀。比如 "你好Rust" 限制为 5 字节时，不能切出半个“好”，结果应该是 "你"。

fn utf8_prefix(text: &str, max_bytes: usize) -> &str {
    // 在这里完成
    todo!()
}

fn utf8_prefix(text: &str, max_bytes: usize) -> &str {
    let mut end = max_bytes.min(text.len());
 
    while !text.is_char_boundary(end) {
        end -= 1;
    }
 
    &text[..end]
}

动手题：给浮点阈值加上输入防线

实现 validate_ratio：输入必须是有限浮点数，并且位于 0.0..=1.0。NaN、正负无穷和范围外数值都返回错误。

fn validate_ratio(value: f64) -> Result<f64, &'static str> {
    if !value.is_finite() {
        return Err("比例必须是有限数值");
    }
 
    if !(0.0..=1.0).contains(&value) {
        return Err(

学完这一章，你不需要立刻记住每个原始类型的全部方法。更值得形成的是一套检查顺序：数值有没有范围和精度要求，运算溢出时业务想要什么，字符串位置按字节、标量还是字形计算，转换是否可能丢信息。编译器会继续在这些地方追问你。把它当成一个严格但负责的搭档，给出明确答案，代码也就有了明确行为。

这里不使用 saturating_add，因为题目要求调用方知道溢出发生了；也不使用 wrapping_add，因为失败次数回到零没有业务意义。

这个答案保证 UTF-8 合法，但它按 Unicode 标量边界截断，不保证保留完整的用户可见字形。若文本包含组合符号或多标量 emoji，还需要更高层的字形分段规则。

先检查 is_finite 能让意图更清楚。只做范围判断时，NaN 也不会落进正常范围，但错误信息会把它和普通越界混在一起。