本文深入探讨了在TypeScript中使用Zod库时，如何构建一个泛型函数，使其在接受自定义配置（特别是Zod验证器）时，能够精确推断并维护其返回类型。通过高级泛型、条件类型和`infer`关键字，我们解决了类型丢失的问题，确保了代码的类型安全和可扩展性。
在构建可扩展的TypeScript应用时，我们经常会遇到需要定义一个函数，该函数接受一个配置对象，并且该配置对象中的某个属性（例如，一个验证器）可以被用户自定义。理想情况下，当用户提供自定义验证器时，函数的返回类型应该能够根据这个自定义验证器进行精确推断，而不是简单地回退到any类型。
考虑以下场景：我们有一个definePlugin函数，它接受一个实现了PluginConfig接口的对象。PluginConfig包含一个可选的Zod验证器，默认为EmailValidator。当用户提供一个自定义的CustomValidator时，我们期望definePlugin的返回值类型能够反映CustomValidator的结构，但实际情况是，TypeScript将其推断为any。
import { z } from 'zod';
export const EmailValidator = z.object({
email: z.string().email()
});
interface PluginConfig {
validator?: z.ZodType; // 问题：z.ZodType 是一个值，而不是一个可推断的类型参数
}
const definePlugin = <T extends PluginConfig = { validator?: typeof EmailValidator }>({
validator = EmailValidator
}: T) => {
return validator.parse({}); // 返回类型被推断为 any
};
const test = definePlugin({});
test.email; // 预期有类型，实际是 any
const CustomValidator = z.object({
email: z.string(),
username: z.string()
});
interface CustomConfig {
validator?: typeof CustomValidator;
}
const test2 = definePlugin<CustomConfig>({
validator: CustomValidator
});
test2.username; // 预期有类型，实际是 any上述代码的问题在于，PluginConfig接口中的validator属性被定义为z.ZodType，这只是一个通用的Zod类型构造器，TypeScript无法从中推断出具体的结构。此外，definePlugin的泛型参数T虽然限制了输入，但并没有将具体的validator类型信息传递到函数的返回类型推断中。
在深入解决方案之前，我们先回顾两个关键概念：
要解决上述类型丢失问题，我们需要结合使用泛型、条件类型和infer关键字，以实现精确的类型推断。
首先，我们需要让PluginConfig接口本身成为泛型，这样它就可以捕获其validator属性的具体ZodType。
import { z, ZodType } from "zod";
// 默认验证器
export const EmailValidator = z.object({
email: z.string().default("")
});
// 泛型化的 PluginConfig 接口
// T 限制为 ZodType，默认值为 EmailValidator 的类型
interface PluginConfig<T extends ZodType = typeof EmailValidator> {
validator?: T;
}这里，PluginConfig<T extends ZodType = typeof EmailValidator>表示PluginConfig现在接受一个类型参数T，T必须是ZodType的子类型。如果没有提供T，它将默认为EmailValidator的类型。
接下来是definePlugin函数的核心改造，它将利用泛型和条件类型来精确推断返回类型。
const definePlugin = <
// T: 传入的配置类型，默认为 PluginConfig<typeof EmailValidator>
T extends PluginConfig = PluginConfig<typeof EmailValidator>,
// R: 从 T 中推断出具体的 ZodType
R = T extends PluginConfig<infer V> ? V : ZodType
>(
{
validator = EmailValidator
}: T
): R extends ZodType<infer P> ? P : never => {
// 这里的 as any 是一个权宜之计，因为 TypeScript 编译器有时难以精确推断
// 运行时 validator.parse({}) 的返回类型，但外部的类型注解已确保类型安全。
return validator.parse({}) as any;
};我们来详细解析definePlugin的泛型签名和返回类型：
T extends PluginConfig = PluginConfig<typeof EmailValidator>:
R = T extends PluginConfig<infer V> ? V : ZodType:
(): R extends ZodType<infer P> ? P : never:
return validator.parse({}) as any;:
现在，让我们使用最终的解决方案来验证类型推断是否正确。
import { z, ZodType } from "zod";
// 创建默认验证器
export const EmailValidator = z.object({
email: z.string().default("")
});
// 泛型化的 PluginConfig 接口
interface PluginConfig<T extends ZodType = typeof EmailValidator> {
validator?: T;
}
const definePlugin = <
T extends PluginConfig = PluginConfig<typeof EmailValidator>,
R = T extends PluginConfig<infer V> ? V : ZodType
>({
validator = EmailValidator
}: T): R extends ZodType<infer P> ? P : never => {
return validator.parse({}) as any;
};
// 使用默认验证器
const test = definePlugin({});
// 此时 test 的类型为 { email: string; }
console.log(test.email); // 正确推断，无类型错误
// 创建自定义验证器
const CustomValidator = z.object({
email: z.string().default(""),
username: z.string().default("")
});
// 创建自定义配置类型
type CustomConfig = PluginConfig<typeof CustomValidator>;
// 使用自定义验证器
const test2 = definePlugin<CustomConfig>({
validator: CustomValidator
});
// 此时 test2 的类型为 { email: string; username: string; }
console.log(test2.username); // 正确推断，无类型错误
console.log(test2.email); // 正确推断，无类型错误通过上述代码，我们可以看到test和test2变量的类型都得到了精确的推断，不再是any。这证明了我们的高级泛型和类型推断策略是成功的。
通过掌握这些高级TypeScript泛型技巧，我们可以构建出更加健壮、可维护且类型安全的应用程序，充分发挥TypeScript和Zod的强大功能。
以上就是在TypeScript函数中覆盖接口并保持Zod返回类型的正确推断的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
广告
收藏
收藏
收藏
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
849
