// 错误示范：没考虑到 name 可Neng为 undefined
function greet {
  return 'Hello ' + name.toUpperCase; // 一旦 name 是 undefined，直接炸裂
}

利用可选链和空值合并运算符Ke以极大地提高代码健壮性。

// 正确示范：防御性编程
function greet {
  return name ? 'Hello ' + name.toUpperCase : 'Hello';
}
// 或者geng现代的写法
const username = user?.profile?.name ?? 'Anonymous';

尽量避免写出不处理空值的代码，空值检查是常识，不是可选项。

Ru果你发现自己正在复制粘贴一段代码，仅仅是为了把 string 换成 number，那你绝对需要泛型了。泛型是 TypeScript 强大 性的体现，它Neng让你写出适应多种类型的代码，而不牺牲类型安全。

// 错误示范：为了不同类型写重复函数
function wrapString: string {
  return ;
}
function wrapNumber: number {
  return ;
}

kan着就累，对吧？这时候泛型就派上用场了。

// 正确示范：一个泛型搞定所有
function wrap: T {
  return ;
}

泛型Neng让你的类型geng具 性和复用性。别让重复代码污染你的项目，学会抽象，你的代码会优雅hen多。

TypeScript 提供了大量内置的工具类型，比如 PartialPickOmitRecord 等等。这些工具Neng帮你以极低的成本操作类型。

但我经常kan到有人手动去复制一个接口，然后删掉几个属性，仅仅为了创建一个“预览版”类型。这不仅容易出错，而且一旦原接口变了你还得手动改所有地方。

// 错误示范：手动复制粘贴，维护困难
interface User {
  id: number;
  name: string;
  age: number;
}
type UserPreview = {
  id: number;
  name: string;
};

为什么不直接用 Pick 呢？

// 正确示范：一行代码，语义清晰
type UserPreview = Pick;

合理使用工具类型，写出geng简洁geng灵活的代码。这是从“会用 TS”到“精通 TS”的必经之路。

关于 interface 和 type 的争论从未停止过。虽然它们在hen多场景下功Neng类似，但并不完全等同。

hen多新手在同一个项目里一会儿用 interface，一会儿用 type，完全没有章法。甚至会出现同名冲突的情况。

// 错误示范：混用导致冲突
type User = {
  name: string;
};
interface User {
  age: number;
} // 冲突！

一般来说interface geng适合定义对象的形状，尤其是需要被 extends 或 implements 的场景；而 type geng适合定义联合类型、交叉类型、元组等复杂类型组合。

// 正确示范：各司其职
interface User {
  name: string;
  age: number;
}
type ID = number | string;

保持团队内部的风格统一非常重要，别让代码变成大杂烩。

这是老生常谈了但在 TypeScript 项目里依然常见。== 会进行隐式类型转换，这往往会带来意料之外的 bug。

// 错误示范：隐式转换风险
if  {
  // 可Neng同时为 undefined 或 null，但也可Neng匹配其他弱类型相等的值
}

在 TypeScript 中，既然我们Yi经明确了类型，就应该彻底杜绝这种模糊地带。始终使用 === 和 !==。

// 正确示范：明确判断
if  {
  // 只有当 value 严格等于 null 时才执行
}

有些同学为了快速上手，或者在项目初期为了“减少报错”，习惯把 tsconfig.json 里的 strict 设为 false。这简直是自废武功。

strict 模式是 TypeScript 中Zui核心的类型检查开关。它开启了一系列严格的检查规则，比如 noImplicitAnystrictNullChecksstrictFunctionTypes 等等。关闭它，会让hen多问题“躲”过编译器，等到上线后才爆发。

{
  "compilerOptions": {
    "strict": true
  }
}

开启 strict 模式，是 TypeScript 真正发挥威力的前提。虽然一开始改起来会hen痛苦，但长远来kan，它Neng帮你省下无数个调试通宵的夜晚。

当你kan到一个函数的参数定义里写了一长串的对象类型时是不是觉得头大？这种写法不仅难以阅读，而且Ru果其他地方也需要用到这个结构，你只Neng无奈地再复制一遍。

// 错误示范：类型写死在参数里
function login {
  // ...
}

把类型抽离出来吧！给它起个有意义的名字。这不仅让函数签名geng清晰，也方便了类型的复用和导出。

// 正确示范：类型抽离
interface LoginParams {
  username: string;
  password: string;
}
function login {
  // ...
}

类型应当抽离，复用geng方便，代码geng清晰。

写好 TypeScript 其实并不难，关键在于理解类型系统的设计意图，并养成良好的编码习惯。不要把 TS 当作负担，它是你构建稳健应用的护城河。

从今天起，试着改掉这些坏习惯：少用 any，多用泛型；别怕 strict，拥抱类型检查；善用工具类型，拒绝重复劳动。相信我，当你回过头来kan自己几个月前写的代码时你会感谢那个Zuo出了改变的自己。

毕竟谁不想写出一套既漂亮又安全的代码呢？加油吧，TypeScript 大师！