类、抽象类、抽象方法这三个概念在TypeScript里经常被放在一起讲但落到真实项目里它们其实是一条连续的决策链什么时候用普通类什么时候把基类设计成抽象类抽象方法到底比接口强在哪里很多人并没有系统想过。我见过一些团队把抽象类当成接口的替代品类里只写方法签名一点实现都不放白白浪费了抽象类最有价值的部分也见过另一种极端把十几个派生类的公共逻辑全部堆进基类结果新增子类时被迫实现一堆跟自己业务无关的抽象方法改一处就牵连一片。这篇文章想用更贴近实战的方式把这层关系拆开讲透。我会从TypeScript类的基本成员体系讲起再进入抽象类和抽象方法的设计意图最后用一个文件解析器的完整示例把从“为什么抽象”到“抽象到什么程度”的全过程走一遍。不管你是刚开始写TypeScript的新手还是写过一阵子但没系统梳理过面向对象设计的老手看完都应该能做出更合理的设计决策。1. 类的角色TypeScript在JavaScript之上加的那些东西1.1 类型标注与编译期检查JavaScript从ES6开始有了class语法但它的本质仍然是基于原型链的语法糖。TypeScript在这个基础上补齐了JavaScript一直缺的东西类型标注、访问修饰符以及编译期的类型检查。先看一个最普通的TypeScript类class User { name: string; age: number; constructor(name: string, age: number) { this.name name; this.age age; } getProfile(): string { return ${this.name}${this.age}岁; } } const user new User(userA, 28); console.log(user.getProfile());这段代码如果去掉类型标注几乎就是JavaScript。但关键差别在于name和age在编译期就被锁定为string和number如果你不小心给age赋了一个字符串TypeScript会立刻报错而不是等到运行时才发现。这就是TypeScript的类的核心价值——用编译期的约束换取运行期的稳定。1.2 构造器参数属性一个容易忽略的高频写法很多人在类里写属性时习惯“先声明、再赋值”class User { public name: string; private email: string; constructor(name: string, email: string) { this.name name; this.email email; } }TypeScript提供了一种更简洁的写法叫参数属性Parameter Properties直接在构造器参数前加访问修饰符编译器会自动帮你完成“声明属性 赋值”两步class User { constructor( public name: string, private email: string, protected age: number ) {} }这段代码和上面那段完全等价。这个写法在React类组件、服务层类、领域模型里都很常见省去了大量样板代码。不过要提醒一点参数属性属于TypeScript的语法特性不是标准JavaScript所以在写纯JavaScript项目或使用某些不支持该语法的编译器目标时要确认工具链是否支持。1.3 访问修饰符的范围与运行时真相TypeScript提供三个访问修饰符它们的可见范围是public默认值类内部、子类、外部都能访问。private只能在当前类内部访问子类和外部都不行。protected当前类和子类内部可以访问外部不行。这些修饰符带来的直接好处是类对外暴露的API边界变得清晰。比如一个密码字段标成private外部代码在编译期就无法直接读取你不用担心有人不小心把它打印到日志里。但这里有一个必须知道的真相TypeScript的private和protected是编译期的约束编译成JavaScript之后它们会变成普通的可访问属性。也就是说运行时如果有人刻意通过(user as any).password这种方式还是能读到私有属性。如果你需要真正的运行时私有性应该使用JavaScript原生的#私有字段class User { #password: string; constructor(password: string) { this.#password password; } }#私有字段是ECMAScript标准的一部分编译后运行时也无法在类外部访问。我的建议是普通业务代码用TypeScript的private就够了声明意图、防手滑涉及安全、需要硬约束的场景用#更稳妥。2. 继承是树抽象类是设计意图2.1 extends的基本语义类的继承用extends关键字实现派生类会继承基类的属性和方法class Animal { constructor(public name: string) {} move(distance: number): void { console.log(${this.name} 移动了 ${distance} 米); } } class Dog extends Animal { bark(): void { console.log(汪汪); } } const dog new Dog(旺财); dog.move(10); // 旺财 移动了 10 米 dog.bark(); // 汪汪这里有几个细节需要注意。第一派生类的构造函数必须调用super()而且super()必须在访问this之前调用否则会报错。第二TypeScript的继承是单继承一个类只能继承一个基类这与Java、C等语言的规则类似。第三基类里的private成员子类拿不到protected成员子类可以访问但不能在外部访问。继承是用来表达“is-a”关系的而不是用来复用代码的。如果你的两个类之间只是恰好有几段相似的代码更合理的做法是抽一个公共函数或工具模块而不是强行让一个类继承另一个类。这个判断标准在后面设计抽象类时同样适用。2.2 该不该抽基类的三个信号在真实项目里我判断“要不要抽一个基类”主要看三个信号第一个信号多个类拥有相同属性、相同方法实现。比如多个解析器都要记录文件路径、编码格式都要打印日志这部分逻辑完全可以沉淀到基类。第二个信号多个类共享一套流程只是流程里的某些步骤细节不同。比如导入数据时的“校验-提取-清洗-转换-加载”流程每一步的具体逻辑因数据源而异但流程骨架是一样的。这时候抽象基类加抽象方法是最自然的表达方式。第三个信号你希望约束子类必须提供某些能力。比如所有解析器都必须实现parse方法否则编译无法通过。这种“强制契约”是抽象方法和接口的核心价值。如果上面的信号一个都不满足那就不需要抽象类写一个普通类或者纯函数就好。过早抽象和过度设计在业务代码里往往比“没有抽象”更让人头疼。3. 抽象类半边骨架半边血肉3.1 抽象类的语法约束抽象类用abstract关键字修饰它的核心特点是不能直接实例化但可以包含已实现的方法和未实现的抽象方法。abstract class Animal { constructor(public name: string) {} // 抽象方法只有签名没有实现 abstract makeSound(): void; // 普通方法有完整实现子类可以复用 move(distance: number): void { console.log(${this.name} 移动了 ${distance} 米); } } // 下面这行会报错 // const animal new Animal(未知生物); // error TS2511: Cannot create an instance of an abstract class.抽象类最独特的地方在于它可以把“公共实现”和“公共契约”放在同一个类里。子类继承抽象类后既能直接复用那些已经写好的方法又必须实现抽象方法否则子类自己也会变成抽象类无法实例化。这在设计上意味着什么意味着抽象类是一张“半成品图纸”图纸已经画好了60%的公共结构剩下的40%必须由每个子类根据自己的场景去填充。这个特性是接口做不到的因为接口里只能写形状描述不能放任何实现逻辑。3.2 抽象类和接口的核心差异接口interface和抽象类abstract class都能定义“契约”但它们的定位完全不同用一个表格就能看明白对比维度接口 interface抽象类 abstract class能否实例化不能不能能否包含方法实现不能只能声明可以包含已实现的方法能否有构造函数不能可以有能否有访问修饰符不支持 private/protected支持 public/private/protected能否有静态成员不能可以有继承数量一个类可以实现多个接口一个类只能继承一个抽象类描述能力只描述“有什么形状”既能描述形状也能提供公共行为用一句话概括接口描述的是一个对象“长什么样”抽象类描述的是一族对象“怎么做”。如果你只是需要约束一个类的形状比如要求它有area()和perimeter()方法用接口就够了如果你还需要这些类共享一段实现逻辑比如统一的日志记录、统一的文件读取流程那就该用抽象类。还有一种常见组合接口负责对外暴露契约抽象类负责内部实现公共逻辑具体业务类继承抽象类。这种分层在大型项目里很常见接口保证了模块间的松耦合抽象类避免了重复代码。3.3 抽象属性与抽象访问器抽象类里不仅能声明抽象方法还能声明抽象属性和抽象访问器getter/setter。这在需要“每个子类提供不同配置”的场景下非常有用abstract class Shape { abstract readonly dimensionLabel: string; abstract get area(): number; describe(): string { return ${this.dimensionLabel} 的面积为 ${this.area}; } } class Circle extends Shape { readonly dimensionLabel 圆形; constructor(private radius: number) { super(); } get area(): number { return Math.PI * this.radius * this.radius; } } const circle new Circle(5); console.log(circle.describe()); // 圆形的面积为 78.53981633974483抽象属性同样是一种契约子类必须提供这个属性至于是用普通属性还是getter实现由子类自行决定。抽象访问器则规定了子类必须提供某个getter/setter。这种写法在“基类需要读取子类配置”的场景里特别顺手比如基类的模板方法要使用子类提供的标签、阈值、开关等配置。4. 抽象方法契约定得越清楚后面越省事4.1 抽象方法的语法与实现规则抽象方法就是只声明签名、不写实现的方法用abstract标注方法体直接以分号结尾abstract class FileParser { abstract parse(content: string): Recordstring, any[]; }抽象方法的规则有这几点抽象方法必须在抽象类里普通类不能声明抽象方法。抽象方法不能有方法体。非抽象的派生类必须实现所有抽象方法。派生类如果没实现全部抽象方法它必须仍然是抽象类。抽象方法的参数和返回值类型在子类实现时不能随意收窄。最后一点要展开讲。比如抽象方法声明的是parse(content: string): Recordstring, any[]子类实现时可以返回一个更具体的类型比如Recordstring, string[]这是允许的因为返回类型可以收窄但参数类型不能收窄比如子类不能只接受CsvContent类型的参数因为基类契约要求它能接受任意string。这一点在多人协作时经常被忽略一旦有人把参数类型收窄编译期可能不会立即报错但运行时就会出现类型不匹配的隐患。4.2 重写时的访问级别与override抽象方法默认是public的子类实现时访问级别不能低于抽象声明。也就是说如果抽象方法声明为public子类实现不能把它改成private或protected否则编译器会直接报错。如果抽象方法是protected子类实现时可以提升为public但不能降到private。从TypeScript 4.3开始推荐在重写父类方法时使用override关键字class CsvParser extends FileParser { override parse(content: string): Recordstring, any[] { // 具体实现 } }配合noImplicitOverride编译选项后所有重写父类方法的地方都必须显式写override。这个约束在大型项目中非常有价值当你重构父类、删掉或改名某个方法时编译器会找出所有标记了override的派生类方法避免出现“子类以为自己重写了父类方法实际父类的方法已经不在了”这种静默错误。5. 实操演示一个文件解析器从0到15.1 先拆需求假设现在要做一个数据导入模块需要支持CSV、JSON两种格式的文件解析。初版需求看起来很简单读取文件内容解析成统一的记录数组后续再交给清洗和入库流程。这时候最容易犯的错误是直接写两个独立的类各自实现一遍“读取文件、打印日志、解析、校验结果”的逻辑。前两个类还能忍等第三个解析器加进来重复代码就会变得很难看。正确的做法是先抽公共骨架。分析一下所有解析器都具备这些共性都有文件路径和编码配置。都遵循“读取内容 - 解析 - 校验结果 - 返回统一格式”的流程。都需要打印开始和结束日志。唯一不同的地方就是parse这一步怎么做。这个分析结果天然指向一个抽象基类加抽象方法的设计。5.2 抽象基类的骨架代码基于上面的分析抽象基类可以这样设计abstract class FileParser { protected filePath: string; protected encoding: string; constructor(filePath: string, encoding: string utf-8) { this.filePath filePath; this.encoding encoding; } // 抽象方法子类必须实现各自的解析逻辑 abstract parse(content: string): Recordstring, any[]; // 普通方法所有子类共享的流程骨架 readAndParse(): Recordstring, any[] { console.log([INFO] 开始解析文件${this.filePath}); const rawContent this.readFile(this.filePath); const data this.parse(rawContent); this.validateResult(data); console.log([INFO] 解析完成共 ${data.length} 条记录); return data; } // protected方法子类可能会用到但外部不能直接调用 protected readFile(path: string): string { // 真实项目这里会走文件系统或网络流这里简化处理 return 模拟的文件内容; } private validateResult(data: Recordstring, any[]): void { if (!Array.isArray(data)) { throw new Error(解析结果必须是数组); } } }这个基类有几个设计上的用心之处。parse是抽象方法是整张图纸唯一要求子类填充的部分readAndParse是把流程串起来的模板方法子类完全不需要关心readFile标成protected子类如果需要自定义读取方式可以重写它但外部代码调用不到validateResult标成private因为它只是内部流程的一个校验步骤。5.3 两个具体解析器的实现有了骨架CSV解析器的实现就非常聚焦了class CsvParser extends FileParser { override parse(content: string): Recordstring, any[] { const lines content.split(\n).filter(line line.trim() ! ); if (lines.length 2) { return []; } const headers lines[0].split(,).map(header header.trim()); return lines.slice(1).map(line { const values line.split(,).map(value value.trim()); const record: Recordstring, any {}; headers.forEach((header, index) { record[header] values[index]; }); return record; }); } }JSON解析器同样只需要关心自己的那份逻辑class JsonParser extends FileParser { override parse(content: string): Recordstring, any[] { const data: unknown JSON.parse(content); if (Array.isArray(data)) { return data as Recordstring, any[]; } if (typeof data object data ! null) { return [data as Recordstring, any]; } throw new Error(JSON 根节点必须是对象或数组); } }使用起来调用方只需要创建具体实例调用统一方法const csvParser new CsvParser(/data/users.csv); const records csvParser.readAndParse();如果后续要加一个XML解析器新类只需要继承FileParser实现parse方法然后把它接进工厂或配置表里就行。公共流程一行都不用改这就是抽象类带来的可扩展性。5.4 模板方法模式让骨架“活”起来上面的readAndParse其实就是一个典型的模板方法模式基类定义算法骨架某些步骤延迟到子类实现。再举一个更明显的例子一个数据导入流程abstract class DataImporter { import(): void { this.validateSource(); const rawData this.extract(); const cleanedData this.clean(rawData); const transformedData this.transform(cleanedData); this.load(transformedData); } protected validateSource(): void { console.log(校验数据源是否可用...); } // 默认的空实现子类如果不需要清洗可以不重写 protected clean(rawData: unknown): unknown { return rawData; } protected abstract extract(): unknown; protected abstract transform(rawData: unknown): unknown; protected abstract load(data: unknown): void; }这里extract、transform、load是抽象方法每个子类必须实现validateSource有默认实现子类可以重写也可以不重写clean是一个“钩子方法”默认什么都不做需要清洗的子类重写它就行。模板方法模式的价值在于流程的骨架被固化在基类里任何人新增一个导入器都按照骨架的节奏来不会出现“A导入器忘了校验B导入器忘了清理”这种不一致问题。我在实际项目中用这个模式重构过一个数据同步模块把原来每个同步器都各自维护的一套流程收敛到基类里新增数据源的时间从一天缩短到半天。6. 踩坑记录与排查速查6.1 报错Non-abstract class ... does not implement ...最常见的编译错误是这个Non-abstract class CsvParser does not implement inherited abstract member parse from class FileParser.原因很简单子类忘了实现抽象方法或者方法签名不匹配。这类错误在编译期就能发现是好事因为它意味着检查器救了你一次。排查思路是先看报错里提到的是哪个抽象成员然后去子类里补上对应方法注意参数类型和返回类型要和抽象声明兼容。需要特别注意的是有时候你会遇到一个抽象类继承另一个抽象类的情况这时候“未实现的抽象方法”可以继续往下传递abstract class BaseParser { abstract parse(content: string): Recordstring, any[]; } abstract class StreamingParser extends BaseParser { abstract streamParse(content: string): void; // parse 没有实现StreamingParser 仍然是抽象类 } class ChunkParser extends StreamingParser { override parse(content: string): Recordstring, any[] { return []; } override streamParse(content: string): void {} }这种传递是合法的但层级拉得太长会增加理解成本。我的建议是抽象类不超过两层超过之后就要考虑是不是设计过度了。6.2 在基类构造函数里调用抽象方法这是我在真实项目里踩过最重的一个坑。看这段代码abstract class BaseParser { constructor() { // 看起来没问题但实际很危险 this.init(); } abstract init(): void; } class CsvParser extends BaseParser { filePath: string ; override init(): void { console.log(初始化文件路径${this.filePath}); } } const parser new CsvParser(); // 输出初始化文件路径 // filePath 此时还没有赋值是空字符串问题的根源在于JavaScript和TypeScript的初始化顺序基类构造函数先执行此时派生类的实例字段还没初始化。上面例子里filePath声明为所以还能兜底如果声明为string类型但没有初始值运行时就会报Cannot read properties of undefined。经验法则是不要在构造函数里调用抽象方法。如果确实需要在创建对象时执行“初始化”逻辑可以把初始化步骤从构造函数里拆出去让调用方显式调用init()或者用工厂函数在创建实例后再触发初始化。这个坑隐蔽在“编译期不报错、运行时才炸”排查时很容易让人怀疑是异步问题实际却是初始化顺序问题。6.3 抽象类的运行时真相与new.target还有一个很多人不知道的细节抽象类编译成JavaScript之后abstract关键字会被完全抹掉运行时并没有“抽象类”这个概念。// 编译前 abstract class Animal { abstract makeSound(): void; } // 编译后简化 class Animal { }这意味着如果你不做额外处理运行时其实是可以直接new Animal()的只是缺少makeSound方法后续调用会报错。如果需要运行时也禁止实例化抽象类可以在构造函数里用new.target做一次检查abstract class Animal { constructor() { if (new.target Animal) { throw new Error(Animal 是抽象类不能直接实例化); } } }new.target指向实际被new的那个类。如果是子类实例化new.target是子类检查不通过如果是直接new Animal()new.target就是Animal抛错。这个技巧在维护长期运行的库或框架代码时很实用但普通业务项目里编译期约束通常已经足够。6.4 接口、抽象类、实现类三者的边界拿捏最后聊一个设计层面的排查。很多人在写TypeScript时纠结“这个功能用接口还是抽象类”我给一个简单可执行的判断流程先问自己这些类之间是否有共享的实现代码如果没有只让它们遵守同一个形状约束用接口。如果有共享实现再问这部分共享逻辑是不是它们业务的核心流程是用抽象类只是零散的公共函数抽工具函数就够了。还有一类用法值得记住抽象类可以实现接口且不需要把接口成员全部实现完没实现的成员可以以抽象成员的身份继续存在interface HasArea { area(): number; } abstract class BaseShape implements HasArea { abstract area(): number; // 接口成员 area 在这里被转声明为抽象方法 // 后续具体子类再实现接口和抽象类的优点都占住了 }这样组合的好处是对外你暴露的是干净的接口契约对内你保留了公共实现的复用能力。我在一个报表导出模块里就用过这种结构接口定义了“导出”能力抽象类实现了数据获取、分页、日志这些公共流程具体导出器只需要负责格式转换。后来新增导出格式时只改了新增文件原有的接口调用方一行没动。类、抽象类、抽象方法这三个东西说到底都是工具工具的意义在于让代码更容易维护和扩展而不在于“用了高级语法就代表设计得好”。我在实际开发中最大的体会是判断一个抽象设计好不好不要看它当时多优雅要看三个月后别人接手时能不能不看基类也能秒懂怎么新增一个子类。如果答案是不行那这个抽象就是失败的和用什么关键字、什么修饰符无关。希望这篇文章能帮你少走一些弯路写出真正经得起时间考验的TypeScript代码。 
长河君 · 2026/10/12 19:26:45 · 阅读 1.2k TypeScript类与抽象类设计：从普通类到抽象方法的实战决策指南
类、抽象类、抽象方法这三个概念在TypeScript里经常被放在一起讲但落到真实项目里它们其实是一条连续的决策链什么时候用普通类什么时候把基类设计成抽象类抽象方法到底比接口强在哪里很多人并没有系统想过。我见过一些团队把抽象类当成接口的替代品类里只写方法签名一点实现都不放白白浪费了抽象类最有价值的部分也见过另一种极端把十几个派生类的公共逻辑全部堆进基类结果新增子类时被迫实现一堆跟自己业务无关的抽象方法改一处就牵连一片。这篇文章想用更贴近实战的方式把这层关系拆开讲透。我会从TypeScript类的基本成员体系讲起再进入抽象类和抽象方法的设计意图最后用一个文件解析器的完整示例把从“为什么抽象”到“抽象到什么程度”的全过程走一遍。不管你是刚开始写TypeScript的新手还是写过一阵子但没系统梳理过面向对象设计的老手看完都应该能做出更合理的设计决策。1. 类的角色TypeScript在JavaScript之上加的那些东西1.1 类型标注与编译期检查JavaScript从ES6开始有了class语法但它的本质仍然是基于原型链的语法糖。TypeScript在这个基础上补齐了JavaScript一直缺的东西类型标注、访问修饰符以及编译期的类型检查。先看一个最普通的TypeScript类class User { name: string; age: number; constructor(name: string, age: number) { this.name name; this.age age; } getProfile(): string { return ${this.name}${this.age}岁; } } const user new User(userA, 28); console.log(user.getProfile());这段代码如果去掉类型标注几乎就是JavaScript。但关键差别在于name和age在编译期就被锁定为string和number如果你不小心给age赋了一个字符串TypeScript会立刻报错而不是等到运行时才发现。这就是TypeScript的类的核心价值——用编译期的约束换取运行期的稳定。1.2 构造器参数属性一个容易忽略的高频写法很多人在类里写属性时习惯“先声明、再赋值”class User { public name: string; private email: string; constructor(name: string, email: string) { this.name name; this.email email; } }TypeScript提供了一种更简洁的写法叫参数属性Parameter Properties直接在构造器参数前加访问修饰符编译器会自动帮你完成“声明属性 赋值”两步class User { constructor( public name: string, private email: string, protected age: number ) {} }这段代码和上面那段完全等价。这个写法在React类组件、服务层类、领域模型里都很常见省去了大量样板代码。不过要提醒一点参数属性属于TypeScript的语法特性不是标准JavaScript所以在写纯JavaScript项目或使用某些不支持该语法的编译器目标时要确认工具链是否支持。1.3 访问修饰符的范围与运行时真相TypeScript提供三个访问修饰符它们的可见范围是public默认值类内部、子类、外部都能访问。private只能在当前类内部访问子类和外部都不行。protected当前类和子类内部可以访问外部不行。这些修饰符带来的直接好处是类对外暴露的API边界变得清晰。比如一个密码字段标成private外部代码在编译期就无法直接读取你不用担心有人不小心把它打印到日志里。但这里有一个必须知道的真相TypeScript的private和protected是编译期的约束编译成JavaScript之后它们会变成普通的可访问属性。也就是说运行时如果有人刻意通过(user as any).password这种方式还是能读到私有属性。如果你需要真正的运行时私有性应该使用JavaScript原生的#私有字段class User { #password: string; constructor(password: string) { this.#password password; } }#私有字段是ECMAScript标准的一部分编译后运行时也无法在类外部访问。我的建议是普通业务代码用TypeScript的private就够了声明意图、防手滑涉及安全、需要硬约束的场景用#更稳妥。2. 继承是树抽象类是设计意图2.1 extends的基本语义类的继承用extends关键字实现派生类会继承基类的属性和方法class Animal { constructor(public name: string) {} move(distance: number): void { console.log(${this.name} 移动了 ${distance} 米); } } class Dog extends Animal { bark(): void { console.log(汪汪); } } const dog new Dog(旺财); dog.move(10); // 旺财 移动了 10 米 dog.bark(); // 汪汪这里有几个细节需要注意。第一派生类的构造函数必须调用super()而且super()必须在访问this之前调用否则会报错。第二TypeScript的继承是单继承一个类只能继承一个基类这与Java、C等语言的规则类似。第三基类里的private成员子类拿不到protected成员子类可以访问但不能在外部访问。继承是用来表达“is-a”关系的而不是用来复用代码的。如果你的两个类之间只是恰好有几段相似的代码更合理的做法是抽一个公共函数或工具模块而不是强行让一个类继承另一个类。这个判断标准在后面设计抽象类时同样适用。2.2 该不该抽基类的三个信号在真实项目里我判断“要不要抽一个基类”主要看三个信号第一个信号多个类拥有相同属性、相同方法实现。比如多个解析器都要记录文件路径、编码格式都要打印日志这部分逻辑完全可以沉淀到基类。第二个信号多个类共享一套流程只是流程里的某些步骤细节不同。比如导入数据时的“校验-提取-清洗-转换-加载”流程每一步的具体逻辑因数据源而异但流程骨架是一样的。这时候抽象基类加抽象方法是最自然的表达方式。第三个信号你希望约束子类必须提供某些能力。比如所有解析器都必须实现parse方法否则编译无法通过。这种“强制契约”是抽象方法和接口的核心价值。如果上面的信号一个都不满足那就不需要抽象类写一个普通类或者纯函数就好。过早抽象和过度设计在业务代码里往往比“没有抽象”更让人头疼。3. 抽象类半边骨架半边血肉3.1 抽象类的语法约束抽象类用abstract关键字修饰它的核心特点是不能直接实例化但可以包含已实现的方法和未实现的抽象方法。abstract class Animal { constructor(public name: string) {} // 抽象方法只有签名没有实现 abstract makeSound(): void; // 普通方法有完整实现子类可以复用 move(distance: number): void { console.log(${this.name} 移动了 ${distance} 米); } } // 下面这行会报错 // const animal new Animal(未知生物); // error TS2511: Cannot create an instance of an abstract class.抽象类最独特的地方在于它可以把“公共实现”和“公共契约”放在同一个类里。子类继承抽象类后既能直接复用那些已经写好的方法又必须实现抽象方法否则子类自己也会变成抽象类无法实例化。这在设计上意味着什么意味着抽象类是一张“半成品图纸”图纸已经画好了60%的公共结构剩下的40%必须由每个子类根据自己的场景去填充。这个特性是接口做不到的因为接口里只能写形状描述不能放任何实现逻辑。3.2 抽象类和接口的核心差异接口interface和抽象类abstract class都能定义“契约”但它们的定位完全不同用一个表格就能看明白对比维度接口 interface抽象类 abstract class能否实例化不能不能能否包含方法实现不能只能声明可以包含已实现的方法能否有构造函数不能可以有能否有访问修饰符不支持 private/protected支持 public/private/protected能否有静态成员不能可以有继承数量一个类可以实现多个接口一个类只能继承一个抽象类描述能力只描述“有什么形状”既能描述形状也能提供公共行为用一句话概括接口描述的是一个对象“长什么样”抽象类描述的是一族对象“怎么做”。如果你只是需要约束一个类的形状比如要求它有area()和perimeter()方法用接口就够了如果你还需要这些类共享一段实现逻辑比如统一的日志记录、统一的文件读取流程那就该用抽象类。还有一种常见组合接口负责对外暴露契约抽象类负责内部实现公共逻辑具体业务类继承抽象类。这种分层在大型项目里很常见接口保证了模块间的松耦合抽象类避免了重复代码。3.3 抽象属性与抽象访问器抽象类里不仅能声明抽象方法还能声明抽象属性和抽象访问器getter/setter。这在需要“每个子类提供不同配置”的场景下非常有用abstract class Shape { abstract readonly dimensionLabel: string; abstract get area(): number; describe(): string { return ${this.dimensionLabel} 的面积为 ${this.area}; } } class Circle extends Shape { readonly dimensionLabel 圆形; constructor(private radius: number) { super(); } get area(): number { return Math.PI * this.radius * this.radius; } } const circle new Circle(5); console.log(circle.describe()); // 圆形的面积为 78.53981633974483抽象属性同样是一种契约子类必须提供这个属性至于是用普通属性还是getter实现由子类自行决定。抽象访问器则规定了子类必须提供某个getter/setter。这种写法在“基类需要读取子类配置”的场景里特别顺手比如基类的模板方法要使用子类提供的标签、阈值、开关等配置。4. 抽象方法契约定得越清楚后面越省事4.1 抽象方法的语法与实现规则抽象方法就是只声明签名、不写实现的方法用abstract标注方法体直接以分号结尾abstract class FileParser { abstract parse(content: string): Recordstring, any[]; }抽象方法的规则有这几点抽象方法必须在抽象类里普通类不能声明抽象方法。抽象方法不能有方法体。非抽象的派生类必须实现所有抽象方法。派生类如果没实现全部抽象方法它必须仍然是抽象类。抽象方法的参数和返回值类型在子类实现时不能随意收窄。最后一点要展开讲。比如抽象方法声明的是parse(content: string): Recordstring, any[]子类实现时可以返回一个更具体的类型比如Recordstring, string[]这是允许的因为返回类型可以收窄但参数类型不能收窄比如子类不能只接受CsvContent类型的参数因为基类契约要求它能接受任意string。这一点在多人协作时经常被忽略一旦有人把参数类型收窄编译期可能不会立即报错但运行时就会出现类型不匹配的隐患。4.2 重写时的访问级别与override抽象方法默认是public的子类实现时访问级别不能低于抽象声明。也就是说如果抽象方法声明为public子类实现不能把它改成private或protected否则编译器会直接报错。如果抽象方法是protected子类实现时可以提升为public但不能降到private。从TypeScript 4.3开始推荐在重写父类方法时使用override关键字class CsvParser extends FileParser { override parse(content: string): Recordstring, any[] { // 具体实现 } }配合noImplicitOverride编译选项后所有重写父类方法的地方都必须显式写override。这个约束在大型项目中非常有价值当你重构父类、删掉或改名某个方法时编译器会找出所有标记了override的派生类方法避免出现“子类以为自己重写了父类方法实际父类的方法已经不在了”这种静默错误。5. 实操演示一个文件解析器从0到15.1 先拆需求假设现在要做一个数据导入模块需要支持CSV、JSON两种格式的文件解析。初版需求看起来很简单读取文件内容解析成统一的记录数组后续再交给清洗和入库流程。这时候最容易犯的错误是直接写两个独立的类各自实现一遍“读取文件、打印日志、解析、校验结果”的逻辑。前两个类还能忍等第三个解析器加进来重复代码就会变得很难看。正确的做法是先抽公共骨架。分析一下所有解析器都具备这些共性都有文件路径和编码配置。都遵循“读取内容 - 解析 - 校验结果 - 返回统一格式”的流程。都需要打印开始和结束日志。唯一不同的地方就是parse这一步怎么做。这个分析结果天然指向一个抽象基类加抽象方法的设计。5.2 抽象基类的骨架代码基于上面的分析抽象基类可以这样设计abstract class FileParser { protected filePath: string; protected encoding: string; constructor(filePath: string, encoding: string utf-8) { this.filePath filePath; this.encoding encoding; } // 抽象方法子类必须实现各自的解析逻辑 abstract parse(content: string): Recordstring, any[]; // 普通方法所有子类共享的流程骨架 readAndParse(): Recordstring, any[] { console.log([INFO] 开始解析文件${this.filePath}); const rawContent this.readFile(this.filePath); const data this.parse(rawContent); this.validateResult(data); console.log([INFO] 解析完成共 ${data.length} 条记录); return data; } // protected方法子类可能会用到但外部不能直接调用 protected readFile(path: string): string { // 真实项目这里会走文件系统或网络流这里简化处理 return 模拟的文件内容; } private validateResult(data: Recordstring, any[]): void { if (!Array.isArray(data)) { throw new Error(解析结果必须是数组); } } }这个基类有几个设计上的用心之处。parse是抽象方法是整张图纸唯一要求子类填充的部分readAndParse是把流程串起来的模板方法子类完全不需要关心readFile标成protected子类如果需要自定义读取方式可以重写它但外部代码调用不到validateResult标成private因为它只是内部流程的一个校验步骤。5.3 两个具体解析器的实现有了骨架CSV解析器的实现就非常聚焦了class CsvParser extends FileParser { override parse(content: string): Recordstring, any[] { const lines content.split(\n).filter(line line.trim() ! ); if (lines.length 2) { return []; } const headers lines[0].split(,).map(header header.trim()); return lines.slice(1).map(line { const values line.split(,).map(value value.trim()); const record: Recordstring, any {}; headers.forEach((header, index) { record[header] values[index]; }); return record; }); } }JSON解析器同样只需要关心自己的那份逻辑class JsonParser extends FileParser { override parse(content: string): Recordstring, any[] { const data: unknown JSON.parse(content); if (Array.isArray(data)) { return data as Recordstring, any[]; } if (typeof data object data ! null) { return [data as Recordstring, any]; } throw new Error(JSON 根节点必须是对象或数组); } }使用起来调用方只需要创建具体实例调用统一方法const csvParser new CsvParser(/data/users.csv); const records csvParser.readAndParse();如果后续要加一个XML解析器新类只需要继承FileParser实现parse方法然后把它接进工厂或配置表里就行。公共流程一行都不用改这就是抽象类带来的可扩展性。5.4 模板方法模式让骨架“活”起来上面的readAndParse其实就是一个典型的模板方法模式基类定义算法骨架某些步骤延迟到子类实现。再举一个更明显的例子一个数据导入流程abstract class DataImporter { import(): void { this.validateSource(); const rawData this.extract(); const cleanedData this.clean(rawData); const transformedData this.transform(cleanedData); this.load(transformedData); } protected validateSource(): void { console.log(校验数据源是否可用...); } // 默认的空实现子类如果不需要清洗可以不重写 protected clean(rawData: unknown): unknown { return rawData; } protected abstract extract(): unknown; protected abstract transform(rawData: unknown): unknown; protected abstract load(data: unknown): void; }这里extract、transform、load是抽象方法每个子类必须实现validateSource有默认实现子类可以重写也可以不重写clean是一个“钩子方法”默认什么都不做需要清洗的子类重写它就行。模板方法模式的价值在于流程的骨架被固化在基类里任何人新增一个导入器都按照骨架的节奏来不会出现“A导入器忘了校验B导入器忘了清理”这种不一致问题。我在实际项目中用这个模式重构过一个数据同步模块把原来每个同步器都各自维护的一套流程收敛到基类里新增数据源的时间从一天缩短到半天。6. 踩坑记录与排查速查6.1 报错Non-abstract class ... does not implement ...最常见的编译错误是这个Non-abstract class CsvParser does not implement inherited abstract member parse from class FileParser.原因很简单子类忘了实现抽象方法或者方法签名不匹配。这类错误在编译期就能发现是好事因为它意味着检查器救了你一次。排查思路是先看报错里提到的是哪个抽象成员然后去子类里补上对应方法注意参数类型和返回类型要和抽象声明兼容。需要特别注意的是有时候你会遇到一个抽象类继承另一个抽象类的情况这时候“未实现的抽象方法”可以继续往下传递abstract class BaseParser { abstract parse(content: string): Recordstring, any[]; } abstract class StreamingParser extends BaseParser { abstract streamParse(content: string): void; // parse 没有实现StreamingParser 仍然是抽象类 } class ChunkParser extends StreamingParser { override parse(content: string): Recordstring, any[] { return []; } override streamParse(content: string): void {} }这种传递是合法的但层级拉得太长会增加理解成本。我的建议是抽象类不超过两层超过之后就要考虑是不是设计过度了。6.2 在基类构造函数里调用抽象方法这是我在真实项目里踩过最重的一个坑。看这段代码abstract class BaseParser { constructor() { // 看起来没问题但实际很危险 this.init(); } abstract init(): void; } class CsvParser extends BaseParser { filePath: string ; override init(): void { console.log(初始化文件路径${this.filePath}); } } const parser new CsvParser(); // 输出初始化文件路径 // filePath 此时还没有赋值是空字符串问题的根源在于JavaScript和TypeScript的初始化顺序基类构造函数先执行此时派生类的实例字段还没初始化。上面例子里filePath声明为所以还能兜底如果声明为string类型但没有初始值运行时就会报Cannot read properties of undefined。经验法则是不要在构造函数里调用抽象方法。如果确实需要在创建对象时执行“初始化”逻辑可以把初始化步骤从构造函数里拆出去让调用方显式调用init()或者用工厂函数在创建实例后再触发初始化。这个坑隐蔽在“编译期不报错、运行时才炸”排查时很容易让人怀疑是异步问题实际却是初始化顺序问题。6.3 抽象类的运行时真相与new.target还有一个很多人不知道的细节抽象类编译成JavaScript之后abstract关键字会被完全抹掉运行时并没有“抽象类”这个概念。// 编译前 abstract class Animal { abstract makeSound(): void; } // 编译后简化 class Animal { }这意味着如果你不做额外处理运行时其实是可以直接new Animal()的只是缺少makeSound方法后续调用会报错。如果需要运行时也禁止实例化抽象类可以在构造函数里用new.target做一次检查abstract class Animal { constructor() { if (new.target Animal) { throw new Error(Animal 是抽象类不能直接实例化); } } }new.target指向实际被new的那个类。如果是子类实例化new.target是子类检查不通过如果是直接new Animal()new.target就是Animal抛错。这个技巧在维护长期运行的库或框架代码时很实用但普通业务项目里编译期约束通常已经足够。6.4 接口、抽象类、实现类三者的边界拿捏最后聊一个设计层面的排查。很多人在写TypeScript时纠结“这个功能用接口还是抽象类”我给一个简单可执行的判断流程先问自己这些类之间是否有共享的实现代码如果没有只让它们遵守同一个形状约束用接口。如果有共享实现再问这部分共享逻辑是不是它们业务的核心流程是用抽象类只是零散的公共函数抽工具函数就够了。还有一类用法值得记住抽象类可以实现接口且不需要把接口成员全部实现完没实现的成员可以以抽象成员的身份继续存在interface HasArea { area(): number; } abstract class BaseShape implements HasArea { abstract area(): number; // 接口成员 area 在这里被转声明为抽象方法 // 后续具体子类再实现接口和抽象类的优点都占住了 }这样组合的好处是对外你暴露的是干净的接口契约对内你保留了公共实现的复用能力。我在一个报表导出模块里就用过这种结构接口定义了“导出”能力抽象类实现了数据获取、分页、日志这些公共流程具体导出器只需要负责格式转换。后来新增导出格式时只改了新增文件原有的接口调用方一行没动。类、抽象类、抽象方法这三个东西说到底都是工具工具的意义在于让代码更容易维护和扩展而不在于“用了高级语法就代表设计得好”。我在实际开发中最大的体会是判断一个抽象设计好不好不要看它当时多优雅要看三个月后别人接手时能不能不看基类也能秒懂怎么新增一个子类。如果答案是不行那这个抽象就是失败的和用什么关键字、什么修饰符无关。希望这篇文章能帮你少走一些弯路写出真正经得起时间考验的TypeScript代码。