你不能让反序列化既失败又不失败。你需要选择一个或另一个。如果API有时返回“意外内容”，那么这种内容是有效模式的一部分，你可以使用例如无标记枚举来表示它。
例如，如果一个字段 * 通常 * 是一个数字，但有时是一个非数字字符串，或者被完全省略，该怎么办？

#[derive(Deserialize)]
#[serde(untagged)]
enum NumberOrString {
    Number(f64),
    String(String),
}

#[derive(Deserialize)]
struct ApiResponse {
    pub some_value: Option<NumberOrString>,
}

现在，您可以处理以下三种情况中的任何一种：

match response.some_value {
    None => { /* Value was null or missing */ }
    Some(NumberOrString::Number(n)) => { /* Value was numeric */ }
    Some(NumberOrString::String(s)) => { /* Value was a string */ }
}

关键是，如果API有时候用一个与API文档描述的模式相矛盾的结构来响应，那么API文档就是错误的。相反，您应该根据API实际返回的内容来建模您的模式。您可能无法提前知道所有的可能性，因此您的程序有时候会无法反序列化响应。当你了解到一个新的特性时，把它编码到你的程序接受的模式中。Rust的强类型特性，包括它强制match arm是穷举的，意味着当你调整模式时，编译器将指出程序中所有需要修改的地方，以考虑新的可能性。