在Unsafe Rust中存储结构体内部数据的'static引用是否合法？API是否Sound？

问题描述 #

我有如下简化的数据结构：

use std::collections::HashMap;
pub struct StringCache {
    // 哈希表的键指向存储在`storage`中的元素
    // 因此绝不会比这个数据结构存活更久。不会对外暴露'static引用
    table: HashMap<&'static str, usize>,

    storage: Vec<Box<str>>,
}

在这里向Rust谎报引用的生命周期是否属于合法/定义行为？在我看来这像是违反了类型系统。此外，该数据结构的公共API是否安全（Sound）？为完整起见，以下是完整实现：

use std::mem::transmute;
impl StringCache {
    pub fn intern(&mut self, entry: &str) -> usize {
        if let Some(key) = self.table.get(entry) {
            return *key;
        }
        let idx = self.storage.len();
        self.storage.push(entry.to_owned().into_boxed_str());
        // 在这里我们把引用强制转换为'static
        let key = unsafe { transmute::<&str, &'static str>(&self.storage[idx]) };
        self.table.insert(key, idx);
        idx
    }
    pub fn lookup(&self, idx: usize) -> &str {
        &self.storage[idx]
    }
}

问题解答 #

1. 谎报生命周期是否合法？ #

这种做法不属于Rust定义的合法行为，本质是用unsafe绕过了生命周期检查，确实违背了类型系统的设计逻辑。

Rust的生命周期标注是内存安全的核心保障之一，用来确保引用不会脱离其指向数据的生命周期。这里把指向storage元素的引用强制转为'static，相当于告诉编译器该引用永远有效，但实际这些引用的生命周期完全绑定在StringCache实例上——一旦实例销毁，storage里的Box<str>会被释放，哈希表中的&'static str就会变成悬垂引用。

尽管当前代码没对外泄露这些'static引用，但这种操作本身已经埋下了未定义行为的隐患。transmute在这里的使用极具风险，它直接篡改了编译器对引用有效性的判断，后续任何内部实现的疏漏（比如误将这些引用导出到外部）都会直接引发内存安全问题。

2. 公共API是否安全（Sound）？ #

从当前的公共API设计来看，是安全的。

原因如下：

• intern方法仅返回索引值usize，不会对外暴露任何内部引用（包括被篡改生命周期的&'static str）；
• lookup返回的&str绑定到&self的生命周期，编译器会自动追踪其有效性，确保它不会超过StringCache实例的存活时间；
• 所有不安全操作都被完全封装在结构体内部，外部调用者无法接触到那些被篡改生命周期的引用，也就不会触发悬垂引用或其他内存安全问题。

需要注意的是，这种安全性依赖于内部实现的严谨性——如果后续修改代码时，不小心将table中的&'static str暴露给外部，或者改变storage的存储方式导致元素被移动/释放，就可能破坏现有的安全保证。

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