解读

面试官抛出此题，往往并非只想听到“会 panic”三个字，而是想确认三点：

1. 候选人是否真正亲手写过带索引的字符串代码，而非只看过书本；
2. 是否理解 Rust 字符串UTF-8 字节序列与“字符”概念的差异；
3. 能否把编译期保证与运行时检查区分开，并给出线上故障的止血方案。
   在国内一线大厂的实际代码库里，因中英混排、表情符号导致的字节边界错位是最高频的 panic 来源之一，面试官希望听到你踩过坑、定位过快、也给出过修复策略。

知识点

• str 与 [u8] 同体：切片操作 &s[i..j] 实际是对底层字节数组做索引，不是字符级切片。
• 运行时边界检查：标准库在 slice index 实现里插入 assert!(i <= j && j <= len)，越界即触发 panic，线程终止，栈回溯由 std::panic_hook 输出。
• panic 与 unsafe 无关：即使代码段被 unsafe 块包裹，只要使用安全 slice 索引语法，边界检查依旧存在；想跳过检查必须裸指针偏移，此时已脱离安全边界。
• no_std 环境：在嵌入式或内核场景，panic_handler 由开发者提供，可直接复位或写看门狗寄存器，行为与 std 线程 panic 不同。
• 恢复策略：业务线程可 catch_unwind 做隔离，但catch 后内存已不可恢复使用，通常只能落日志并重启任务；对延迟敏感的服务会采用预检长度或字符级 API（s.char_indices()）彻底避免 panic。

答案

对安全代码中的字符串切片 &s[i..j]，Rust 在运行时插入边界断言；一旦 i 或 j 超出字节长度，当前线程立即 panic，展开栈并调用默认的 panic_hook 打印文件行号与字节偏移。
panic 属于不可恢复错误，不会返回任何错误码；若程序未自定义 panic_handler，进程最终以 101 退出码终止。
若想避免，应在切片前用 s.len() 或 s.char_indices() 做预检，或改用 get(i..j) 返回 Option，把可能的越界转换成可恢复错误。

拓展思考

1. 生产事故：国内某广告服务曾因用户昵称含表情符号，后端按字节截断 32 字节导致边界落在 UTF-8 续字节，触发 panic 大面积掉线。修复方案是先按字符迭代计算宽度，再回退到最近合法字节边界，而非简单取 len。
2. 性能权衡：对热路径日志切片，可先用get_unchecked 手动跳过检查，但需向上层保证索引来自前置校验；此模式在字节缓存解析框架 tokio-util 中有官方示例。
3. 异步上下文：panic 会污染整个 Tokio 调度线程，即使 catch_unwind 也只能防止传播，无法继续 polling；因此网络协议解码器普遍采用try_get 风格 API，把越界转成 DecodeError，再交由连接层统一回收。