JavaScript老旧项目重构中，继承非核心手段，但合理使用class/extends可提升可读性、可维护性和类型友好度；应识别“is-a”关系，逐步将构造函数+原型写法升级为class，并用extends抽离公共行为，避免无语义的强行继承。
JavaScript 中继承机制本身不是重构老旧项目的核心手段，但合理利用现代继承语法（如 class + extends）可以显著提升老旧基于原型链或工厂函数代码的可读性、可维护性和类型友好度。关键不在于“用继承替代一切”，而在于识别原有逻辑中的“is-a”关系，用更清晰的结构封装复用逻辑。
先理清旧代码的真实继承模式
很多老旧项目其实没有真正意义上的继承，而是：
- 手动复制方法到对象上（“混入”式写法）
- 用
Object.create(prototype)模拟继承但缺乏统一规范 - 大量使用全局函数+参数判断实现多态（比如
render(type, data)） - 构造函数中直接挂载方法，导致无法共享或覆盖
重构前务必用小范围抽样分析：哪些对象在语义上属于同一类事物？哪些行为被多个对象重复实现？这些才是适合用 class 和 extends 整理的信号。
用 class 逐步替代构造函数+原型写法
如果旧代码是类似这样的 ES5 风格：
立即学习“Java免费学习笔记（深入）”；
function Button(text) {
this.text = text;
}
Button.prototype.render = function() {
return `<button>${this.text}</button>`;
};
Button.prototype.click = function(handler) {
// ...
};
可平滑升级为：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
class Button {
constructor(text) {
this.text = text;
}
render() {
return `<button>${this.text}</button>`;
}
click(handler) {
// ...
}
}
注意：不需要重写所有实例方法——只改当前有维护需求的部分；保持新旧共存过渡期，确保测试通过再推进。
用 extends 抽离公共行为，避免重复逻辑
当发现多个 UI 组件（如 Button、Input、Modal）都有 show()、hide()、destroy() 等生命周期方法时，可提取基类：
class UIComponent {
constructor(options = {}) {
this.visible = false;
this.el = null;
}
show() {
this.visible = true;
this.el?.classList.remove('hidden');
}
hide() {
this.visible = false;
this.el?.classList.add('hidden');
}
destroy() {
this.el?.remove();
}
}
class Button extends UIComponent {
constructor(text) {
super();
this.text = text;
}
render() {
this.el = document.createElement('button');
this.el.textContent = this.text;
return this.el;
}
}
这样既保留了原有功能，又让扩展（如加 TooltipButton）变得自然，也方便后续接入框架生命周期钩子。
谨慎处理第三方库或 DOM 封装类的继承
老旧项目常有类似 DomHelper、ApiWrapper 这类工具类。它们通常不具备“实例化后拥有独立状态”的特征，强行用 class 包裹反而增加复杂度。这类更适合：
- 保持为纯函数模块（
export function ajax(...)） - 或用静态类（
class ApiClient { static get(...) {...} }） - 若必须实例化（如带 token 状态），再考虑
class ApiClient extends EventEmitter这类有意义的继承
不要为了用 extends 而继承 —— 没有语义支撑的继承只会让代码更难理解。
