Rust中无内存分配将Vec<&T>转换为&[T]的传参问题

编译报错核心为类型不匹配：

• 通过flat_map+collect得到的是Vec<&EnvVar>类型，最多可转换为&[&EnvVar]切片，切片内存储的是指向EnvVar的指针
• 目标函数some_api要求参数为&[EnvVar]，切片内需要直接连续存储EnvVar实例本身

两种切片内存布局完全不同，不存在安全的直接转换方式。
另外&[T]类型本身存在硬约束：切片内所有T元素必须在内存中连续排列。示例代码里的EnvVar实例分散存储在各个Service各自持有的Vec<EnvVar>中，本身不存在连续排列的EnvVar序列，无法凭空构造出符合要求的&[EnvVar]。

如果可以修改some_api的函数签名，直接把参数改成接受可遍历的EnvVar借用类型即可，完全不需要拷贝数据，甚至可以省去collect成Vec的堆分配开销：

use std::cell::RefCell;
pub struct EnvVar {}

pub struct Arena {
    services: RefCell<Vec<Service>>,
}

pub struct Service {
    env_vars: Vec<EnvVar>,
}

// 修改后的API签名，支持所有能产出&EnvVar的可迭代类型
pub fn some_api<'a>(env_vars: impl IntoIterator<Item = &'a EnvVar>) {
    // 内部直接遍历使用即可，和原有用法完全兼容
    for env_var in env_vars {
        // 业务逻辑
    }
}

fn main() {
    let arena = Arena {
        services: RefCell::new(vec![Service {
            env_vars: vec![EnvVar {}],
        }]),
    };
    // 无需collect，直接传入迭代器，零额外开销
    some_api(
        arena
            .services
            .borrow()
            .iter()
            .flat_map(|svc| svc.env_vars.as_ref())
    );
}

这个方案完全符合不执行Copy/Clone的性能要求，是这类场景的标准处理方式。

如果完全不能改动some_api的签名，必须传入&[EnvVar]，不存在零拷贝解法：只能把所有需要传入的EnvVar克隆到一个连续存储的Vec<EnvVar>中，再取切片传入。
这种场景下不要尝试用任何unsafe手段构造&[EnvVar]，否则会触发未定义行为——分散存储的EnvVar不满足切片的连续内存要求，强行转换会导致内存访问错误。

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