嘿，作为Rust新手能注意到unwrap和expect的差异，这已经是个很棒的开始啦！先给你划个核心结论：这俩方法本质功能完全一致，但expect能帮你在panic时输出更有用的错误信息，而unwrap只会用Rust默认的提示。

先搞懂它们的底层逻辑 #

不管是unwrap还是expect，都是用来从Option<T>或者Result<T, E>里提取内部值的工具：

• 如果是Some(T)/Ok(T)：直接返回里面的T值，你的示例代码里运行cargo run hello就是这种情况，所以两个方法都能正常拿到"hello"。
• 如果是None/Err(E)：立刻触发panic，终止程序运行。

它们的唯一区别，就是panic时抛出的错误内容：

• unwrap()会输出Rust内置的默认消息，比如called Option::unwrap()on aNone value
• expect("自定义消息")会输出你传入的自定义字符串，比如你示例里的the program should be called with a commandline argument

什么时候该用哪个？ #

虽然理论上二者可以互换，但根据场景选对工具能大幅提升调试效率和代码可读性：

• 优先用expect的场景：
  • 当panic发生时需要明确的上下文提示，比如命令行参数、文件读取、网络请求这类依赖外部输入的场景——自定义消息能直接告诉用户/开发者“哪里出问题了”，而不是一堆晦涩的默认报错。
  • 写库代码的时候：库的使用者遇到panic时，自定义的错误消息能帮他们快速定位是库的哪个环节出了问题，而不是对着默认的unwrap报错一脸懵。
  • 任何你觉得“这个地方理论上不会错，但万一错了我得知道为啥”的场景：加个expect相当于给代码加了个调试注释，后面维护代码的人（包括未来的你）能瞬间明白这里的预期是什么。
• 可以用unwrap的场景：
  • 小脚本、快速原型或者一次性代码：你自己能快速定位问题，懒得写自定义消息的时候，unwrap更简洁。
  • 绝对不可能出错的场景：比如你刚手动创建了一个Some(100)，马上调用unwrap——这种情况几乎不会panic，用unwrap完全没问题（不过即使这样，加个expect("这绝对不可能是None")也没坏处，万一后面代码改了呢？）

举个实际对比的例子 #

如果你的代码里用了unwrap，用户忘记传参数直接运行cargo run，会得到这样的报错：

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/main.rs:4:27
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

而如果用expect，报错会变成：

thread 'main' panicked at 'the program should be called with a commandline argument', src/main.rs:6:27
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

显然后者的报错直接点明了问题，用户一看就知道自己漏传了命令行参数。

内容的提问来源于stack exchange，提问作者manikawnth