导航：首页 > 开发技术 >

JavaScript的类出现了什么问题

发表于：2026-11-01 作者：千家信息网编辑

千家信息网最后更新 2026年11月01日，今天就跟大家聊聊有关JavaScript的类出现了什么问题，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。虽然JavaScript类看起来一切正

千家信息网最后更新 2026年11月01日JavaScript的类出现了什么问题

今天就跟大家聊聊有关JavaScript的类出现了什么问题，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。

虽然JavaScript类看起来一切正常，但若你用它一段时间，尤其是之前用过ES5的人，就有可能看见原型继承演变成现行类模式的进程。

为什么呢?原型链出什么问题了?依我拙见，答案是一切正常。但技术界花费了数年的时间，迫使类的概念进入不同的结构和库中，因此ECMA技术委员会决定无论如何都要添加它。

这有什么问题吗?在我们已经拥有的原型继承之上添加了一些组成，并决定将其称为类，这反过来又让开发人员以为他们正在处理一种面向对象的语言，而实际上它们并不是。

类仅仅是语法糖(syntactic sugar)

JavaScript没有OOP的全面支持，因为它从来都不需要OOP。从表面看，现行类版式呈现出OPP范例，因为：

可以定义基本类、分类状态和行为以及特殊经典语法。
可以把一种类沿用到另一种类。
可以定义属性和方法的可行度，公共和私人均可。
可以为属性定义获得者和设置者。
可以忽略类继承的方法。
当然还可以实例化各种类。

我之所以说类是语法糖，是因为尽管表面来看，类看起来非常面向对象，如果做一些超过领域可能性范围的事，如定义一种涉及另外两种类的类(这是目前不可能实现的事)，需要使用如下代码：

//Thehelper function          functionapplyMixins(derivedCtor,baseCtors) {              baseCtors.forEach(baseCtor => {                  Object.getOwnPropertyNames(baseCtor.prototype).forEach(name=> {                      let descriptor =Object.getOwnPropertyDescriptor(baseCtor.prototype, name)                      Object.defineProperty(derivedCtor.prototype, name, descriptor);                  });              });          }          //The parent classes          classA {                 methodA(){                  console.log("A")              }          }          classB {              methodB(){                  console.log("B")              }          }          //The child class          classC {          }          //Using mixins          applyMixins(C, [A, B])          let o =newC()          o.methodA()          o.methodB()

我们需要做这个，因为无法编辑JS：

classA {              methodA(){               console.log("A")           }       }          classB {              methodB(){               console.log("B")           }       }          classCextendsA, B {          }

在某些情况下，这种行为可能会派上用场，JavaScript的员工创建了上面的代码片段，我只是删除了额外的代码，使它适用于普通JS。

但是样本代码的重要信息应该是applyMixins功能。即使不充分理解它的功能，也能发现，它用于评估各种类的原型属性以复制和重分配方法和属性。这是发现事实的全部证据：类只不过是在经过验证的原型继承模型之上的语法糖。

这说明应该停止用类吗?并不是。理解它很重要，如果需要突破类能做和不能做的界限，将不得不处理原型来实现这一点。

JavaScript的OOP 模型错过了什么?

如果现在的OOP模型不够完美，只是原型继承的抽象体，那么我们错过了什么?什么使JS成为真正的OOP?

要解答这个问题，就先要看看JavaScript的功能，语言背后的团队肯定要发明能把JavaScript转换成JS的东西，来把JavaScript推到极限。这反过来也会限制它们的功能，但是，开始OOP愿望列表的一个好方法是查看它们与OOP相关的特性。

你马上会注意到一个警告：目前JavaScript中缺失的一些OOP构造具有内在的类型检查功能，在动态类型语言中没有真正的意义，这可能是因为它们还没有被添加。

接口

这些是很好的结构，有助于定义类应该遵循的API。接口在无类型JS中可能会丢失，它的一个主要好处是，你可以为任何实现相同接口的类定义一个变量，并安全地调用它的任何方法。

interfaceAnimal {             speak()           }          classDog implements Animal{             speak() {               console.log("Woof!")             }           }          classCat implements Animal{             speak() {               console.log("Meau!")             }           }          classHuman implements Animal{             speak() {               console.log("Hey dude, what's up?")             }           }          //if we had Interfaces in JS we could safely do:           let objects = [newDog(), newCat(), newHuman()]           objects.forEach(o => o.speak())

这在普通JS中是无法做到的。当然可以通过定义speak方法并覆盖它的类来实现同样的目的。但话又说回来，也可以在任何其他强OOP语言中这样做，接口更加清晰和简洁。