函数是 TypeScript 类型系统中最常见的使用场景。参数类型、返回值类型和异步返回类型都应该尽量明确。
基本函数类型
function calculateDiscount(price: number, rate: number): number {
return price * rate;
}返回值可以省略让 TypeScript 推断,但在公共函数和复杂函数中显式写出更清晰。
默认参数
function calculateDiscount(price: number, rate: number = 0.5): number {
return price * rate;
}
calculateDiscount(1000);
calculateDiscount(1000, 0.3);默认参数可以减少重复调用配置。
剩余参数
function joinNames(prefix: string, ...names: string[]): string {
return `${prefix}: ${names.join(", ")}`;
}...names 表示可以接收任意多个字符串参数。
Promise 基础
异步函数通常返回 Promise<T>。
async function fetchUser(): Promise<{ id: string; name: string }> {
return { id: "1", name: "Alice" };
}async 会让函数自动返回 Promise,即使你 return 的是普通值。
await
await 用来等待 Promise 完成。
async function main() {
try {
const user = await fetchUser();
console.log(user.name);
} catch (error) {
console.error("Failed to fetch user", error);
}
}实践建议
异步函数建议明确返回值类型。
async function pullContacts(args: {
limit?: number;
page?: number;
}): Promise<ContactList> {
return { contacts: [] };
}这样调用方可以获得更好的类型提示,也能减少接口变更时的隐性错误。
延伸理解
复习这篇时,不要只记住名词,要把重点放在 函数类型、默认参数、剩余参数、Promise、async/await 和错误处理。这类知识如果只停留在定义层面,很容易在面试或项目中答得很散。更好的理解方式是把它放进一个具体场景:谁在调用它,输入从哪里来,失败后谁负责恢复,数据或状态会不会被重复处理。
- TypeScript 的价值是把运行时不确定性尽量前移到开发阶段,但它不能替代运行时校验。
- 类型设计应优先描述业务约束,而不是为了炫技使用复杂泛型。
- 遇到第三方输入、JSON、表单和 API 响应时,要结合类型收窄或 schema 校验。
在真实项目中,可以把它当成一个判断框架:先确认输入、约束、失败场景和可观测性,再决定具体工具或写法。 如果一个方案看起来很简单,要继续追问它在规模扩大、权限变化、异常恢复和团队协作下是否仍然成立。
实践检查清单
- 明确这个知识点在系统中的位置:是开发时约束、运行时能力、基础设施能力,还是协作流程。
- 写出一个最小可运行例子,并补一个失败例子;只会写 happy path 说明理解还不够稳。
- 记录常见误用:例如边界条件、权限假设、性能假设、同步/异步差异或环境差异。
- 把概念和项目经历关联起来:如果面试被追问,可以用自己的项目说明为什么这样选。
- 最后用一句话总结取舍:它牺牲了什么,换来了什么。
自测问题
- 这个主题解决的核心问题是什么?
- 如果不用当前方案,还有哪些替代方案?代价是什么?
- 最容易出错的边界条件在哪里?
- 如何在代码、测试或监控中验证它真的可靠?
项目化应用场景
可以把这类知识放到一个前后端共享类型的项目里理解:API 返回 JSON,前端先用 schema 做运行时校验,再把校验后的数据交给 TypeScript 类型系统。类型可以帮助编辑器提示和编译期检查,但不能保证网络返回一定正确。好的类型设计应该表达业务约束,例如角色、状态、权限、请求参数和响应结构,而不是所有地方都写成 string 或 any。
常见误区:
- 把 TypeScript 类型当成运行时校验。
- 为了省事使用 any,导致错误延后到线上。
- 泛型过度复杂,让调用者难以理解。