JavaScript 规定：所有类默认隐式继承 Object.prototype（因此实例可访问 toString() 等原型方法），但不会继承 Object 构造函数上的静态方法（如 Object.keys()、Object.assign()），这是语言设计的明确取舍，旨在避免命名污染、保持语义清晰与继承链简洁。
javascript 规定：所有类默认隐式继承 `object.prototype`（因此实例可访问 `tostring()` 等原型方法），但**不会继承 `object` 构造函数上的静态方法**（如 `object.keys()`、`object.assign()`），这是语言设计的明确取舍，旨在避免命名污染、保持语义清晰与继承链简洁。
在 JavaScript 中，类继承分为两个正交维度：
- 原型链继承（instance-level）：影响实例对象，决定 obj.method() 能调用哪些方法；
- 构造器/类对象继承（constructor-level）：影响类本身（即 Class.xxx()），决定静态方法是否可被子类访问。
关键事实是：所有类的 prototype 都继承自 Object.prototype，但类本身（构造函数）并不继承 Object 的静态属性。这正是为什么以下代码行为不同：
class Test { }
const test = new Test();
console.log(test.toString()); // ✅ 正常运行 —— 继承自 Object.prototype
console.log(Test.keys({})); // ❌ TypeError: Test.keys is not a function
console.log(Test.assign({}, {})); // ❌ 同样报错为什么这样设计？核心原因有三：
避免静态命名污染与语义混淆
若 Test 自动拥有 Object.create()、Object.getOwnPropertyDescriptor() 等静态方法，会误导开发者认为这些方法与 Test 语义相关（例如误以为 Test.create() 应创建 Test 实例），而实际上它们是通用对象操作工具，与具体类无关。TC39 在 2012 年 ES6 设计会议中明确指出：“polluting statics with everything in Object is fatal”（将 Object 全部静态方法注入每个类是致命的污染）。规避覆盖风险与冻结限制
若类自动继承 Object 静态方法，则当 Object 被冻结（Object.freeze(Object)）后，子类将无法重写同名静态方法（如 keys、values），严重限制类的可扩展性。显式继承（class Test extends Object）才需承担此约束，而默认行为保留了最大灵活性。-
保持与内置构造器行为一致
Array、Function、Date、Error 等内置构造器均遵循同一规则：- Array.prototype → Object.prototype ✅（实例继承 toString）
- Array 构造器本身 → 不继承 Object 静态方法 ❌（Array.keys 不存在）
这一统一模型确保了语言的一致性与可预测性。
补充说明：extends Object 是显式、非默认行为
虽然 class Test extends Object 语法合法，但它不是隐式发生的：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
class Test {}
// 等价于：Test.prototype.__proto__ === Object.prototype
// 但：Test.__proto__ === Function.prototype（而非 Object）
class ExplicitTest extends Object {}
// 此时：ExplicitTest.__proto__ === Object
// 因此 ExplicitTest.keys === Object.keys ✅但该写法极少使用——它强制 Test 必须在构造器中调用 super()，且引入了不必要的继承开销和语义负担。ES6 设计者刻意将“无 extends”设为最简路径（prototype 继承 Object.prototype，但构造器保持轻量），正是出于工程实用性考量。
总结与建议
- ✅ 实例方法（如 toString）可继承：因所有 prototype 链最终指向 Object.prototype；
- ❌ 静态方法（如 Object.keys）不继承：因类构造器默认不参与 Object 的静态继承链；
- ? 若确需继承：可显式 class MyCls extends Object，但应审慎评估必要性；
- ? 替代方案更推荐：直接调用 Object.keys()、Object.assign() 等全局工具函数，语义更清晰，也符合 JavaScript “组合优于继承” 的实践哲学。
这一设计并非疏漏，而是 TC39 在可维护性、语义准确性与向后兼容之间权衡后的深思熟虑——理解它，有助于写出更符合语言直觉、更健壮的面向对象代码。
