bytemuck crate中为何将Copy设为Pod的超trait？

根据bytemuck的文档，Pod是一个标记trait，其定义如下：

pub unsafe trait Pod: Zeroable + Copy + 'static { }

我对标记trait的理解是：这类trait用于声明类型具备无法通过函数/方法描述的特性，以便类型的使用者知晓如何正确处理它们。例如Copy是标记trait，当类型实现Copy后，Rust编译器在处理该类型的a = b操作时会执行按位复制；Send也是标记trait，标记后编译器会认可该类型可安全发送至其他线程。

针对Pod trait的定义，我有以下疑问：

1. 为什么自定义类型声明为Pod时，必须实现Copy？毕竟当我们将类型标记为Pod时，已经是在向bytemuck作出承诺：“这个类型完全符合Pod的要求，可以放心地将字节重新解释为该类型”。
2. 我猜测设计初衷是：bytemuck要防止开发者误将包含非Copy类型（如Vec<u8>、String）的结构体标记为Pod——毕竟“实现Copy”是“成为Pod类型”的必要不充分条件，连Copy都不满足的类型绝不可能是普通旧数据（Plain Old Data）。

但这个设计带来了一个实际问题：如果要标记一个体积极大的类型为Pod，比如下面的结构体：

struct MyStruct {
    data: [u8; 10_000_000],
}

就必须为它实现Copy，这显然不太合理——万一不小心触发了该类型的按位复制，会带来巨大的性能开销。

那么，不将Copy设为Pod的超trait是不是更优的选择？作为代码作者，我愿意为自己标记为Pod的类型承担全部责任。

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