JavaScript对象字面量中定义方法的简写语法

图 1：ES5 传统键值函数与 ES6 方法简写语法的结构演变及内部属性特征对照

什么是方法简写语法及其与传统写法的直观对照

在 ECMAScript 2015 (ES6) 之前，在对象字面量中添加方法只能通过属性键值对的形式，将一个匿名或具名函数表达式赋值给指定属性：

// ES5 传统写法：属性名 + 冒号 + 函数表达式
var user = {
  name: "Alex",
  getName: function() {
    return this.name;
  }
};

而在 ES6 标准引入方法简写语法后，可以省略 : function，直接在对象中书写方法名、参数括号与函数体：

// ES6 简写语法：直接定义方法
const user = {
  name: "Alex",
  getName() {
    return this.name;
  }
};

在日常书写中，简写语法让对象结构的视觉排版更加紧凑清晰，特别是在定义包含大量逻辑方法的配置对象、服务对象或控制器模块时，能消除大量冗余的样板代码。

此时读者通常会产生一个疑问：省略了显式函数声明后，方法的名称标识符是如何表现的？在 ES6 规范中，通过方法简写定义的方法，其内置的 name 属性会自动被设为对应的键名字符串。例如执行 user.getName.name，输出的结果精准为 "getName"；如果是 Symbol 键名，则会提取该 Symbol 的描述信息。

方法简写语法的四种衍生形态与编写规范

方法简写语法并非仅限于最基础的同步函数，它与 JavaScript 的其他现代特性完美兼容，派生出了四种典型的书写形态：

图 2：方法简写语法的四种衍生形态、关键字前置规则与解析流程

1. 常规同步方法

直接通过标识符配合参数列表声明。参数同样支持 ES6 的默认参数、解构赋值与剩余参数（Rest parameters）：

const calculator = {
  sum(base = 0, ...numbers) {
    return numbers.reduce((acc, curr) => acc + curr, base);
  }
};

2. 配合计算属性名（Computed Property Names）

当方法名称需要动态计算、由变量指定或基于 Symbol 声明时，可以将表达式包裹在中括号 [] 中，后方紧跟括号即可：

const ACTION_PREFIX = "handle";
const refreshKey = Symbol("refresh");

const controller = {
  // 字符串拼接表达式计算属性名
  [ACTION_PREFIX + "Click"](event) {
    console.log("处理点击", event);
  },
  // Symbol 唯一标识符方法（常用于内置协议或私有方法模拟）
  [refreshKey]() {
    this.resetState();
  }
};

3. 异步方法与生成器方法

需要定义异步或生成器方法时，关键字的放置规则非常固定：

• 异步方法（Async Methods）：将 async 关键字直接放置在方法名之前。
• 生成器方法（Generator Methods）：在方法名前直接放置星号 *。
• 异步生成器方法（Async Generator Methods）：组合使用 async *methodName()。

const dataStream = {
  // 异步方法
  async fetchRemote(url) {
    const res = await fetch(url);
    return res.json();
  },

  // 生成器方法
  *stepIterator() {
    yield 1;
    yield 2;
  }
};

4. 访问器属性（Getters 与 Setters）

虽然严格来说访问器属于属性定义，但在语法结构上它与简写方法完全相同，通过前置 get 或 set 关键字实现对属性读写的拦截绑定：

const box = {
  _width: 10,
  get width() {
    return this._width;
  },
  set width(val) {
    if (val > 0) this._width = val;
  }
};

底层差异一：不可构造性与运行期内存节约

很多开发者认为方法简写仅仅是少写了几个字符的“语法糖”，但事实并非如此。在 ECMAScript 规范定义中，方法简写与传统函数表达式在底层抽象方法（Internal Methods）上存在本质区别：

我们通过一段具体的对比代码来验证这一行为：

const service = {
  // 传统函数写法
  legacyMethod: function() {},
  // 简写方法写法
  modernMethod() {}
};

// 1. 检查 prototype 属性
console.log(service.legacyMethod.prototype); // 输出: {constructor: ƒ}
console.log(service.modernMethod.prototype); // 输出: undefined

// 2. 尝试使用 new 实例化
new service.legacyMethod(); // 正常执行，返回新创建的空对象
new service.modernMethod(); // 抛出 TypeError: service.modernMethod is not a constructor

为什么标准要做出这一设计？

在传统的 JavaScript 中，每一个常规函数都背负了“双重身份”：它既能作为可执行调用的函数，又能充当制造实例的构造器。这种设计在面向对象开发中带来了两个负面问题：一是每个函数对象在分配内存时，引擎都必须附带创建一个原型对象 .prototype，造成不必要的堆内存占用；二是允许随意 new obj.method() 容易掩盖逻辑设计失误。方法简写语法明确剥离了构造器职责，让方法回归纯粹执行函数的角色，同时也给 JavaScript 引擎提供了优化调用内联缓存（Inline Cache）的空间。

底层差异二：[[HomeObject]] 绑定与 super 关键字支持

方法简写语法的另一个核心能力，在于它原生解锁了 super 关键字在普通对象中的使用。这是传统 key: function() 语法无法做到的。

图 3：[[HomeObject]] 内部槽位与 super 原型链委派机制的调用链路

在原型链继承场景中，如果一个对象的方法需要重写其原型上的同名方法，并在内部调用父级逻辑，过去只能通过 Object.getPrototypeOf(this).method.call(this) 这样冗长且容易在多层继承中发生死循环的代码来实现。

而在方法简写中，JavaScript 引擎在创建方法函数对象时，会静态为其分配一个内部私有槽位 [[HomeObject]]，其值精准指向定义该方法的对象字面量。当在方法体中触发 super.methodName() 时，引擎的执行逻辑如下：

1. 直接查找当前执行函数的 [[HomeObject]]（即当前子对象）；
2. 通过内部机制读取 Object.getPrototypeOf([[HomeObject]]) 获取原型对象；
3. 在原型对象上找到目标方法，并将当前的 this 绑定传入执行。

看下面的具体原型协作示例：

const baseLogger = {
  log(msg) {
    return `[BASE] ${msg}`;
  }
};

const appLogger = {
  log(msg) {
    // 原生通过 super 访问原型对象中的方法
    const baseOutput = super.log(msg);
    return `${baseOutput} -> [APP]`;
  }
};

// 建立原型关联
Object.setPrototypeOf(appLogger, baseLogger);

console.log(appLogger.log("系统初始化"));
// 输出: "[BASE] 系统初始化 -> [APP]"

语法对比矩阵：传统函数、简写方法与箭头函数

很多初学者容易将对象方法简写与 ES6 箭头函数混淆，甚至错误地认为箭头函数也是一种“更简短的方法定义方式”。下表清晰梳理了在对象字面量中定义函数的三种形式及其核心机制差异：

图 4：传统函数属性、方法简写与箭头函数三大模式的核心特性对比矩阵

开发中常见误区与避坑指南

了解了简写语法的优势之后，还需要在实际应用中防范以下三个容易混淆的典型陷阱：

1. 误区一：混淆简写方法与箭头函数的 this 行为

部分初学者误以为方法简写会导致 this 指向外部。必须牢记：方法简写的 this 依旧是动态绑定的。在执行 object.method() 时，this 始终指向调用点左侧的 object。相反，如果错误地将方法写成箭头函数，this 则会指向定义对象时所在的外部作用域（通常是 window 或模块作用域），导致无法通过 this 访问对象的同级属性：

const counter = {
  count: 0,
  // 错误做法：箭头函数无法访问 counter 自身的 count
  badIncrement: () => {
    this.count++; // 这里的 this 不是 counter！
  },
  // 正确做法：方法简写具有标准的动态上下文
  goodIncrement() {
    this.count++; // 正确累加
  }
};

2. 误区二：解构方法导致上下文脱离

正因为方法简写保留了动态 this，当把方法从对象中解构出来单独调用，或者作为异步回调函数传入时，原有的宿主对象上下文会丢失：

const { goodIncrement } = counter;
goodIncrement(); // 报错或计算异常：此时 this 指向 undefined (严格模式)

// 解决方法：传递时显式绑定上下文，或使用箭头函数闭包包裹
setTimeout(() => counter.goodIncrement(), 100);

3. 误区三：方法转移复制后的 super 静态绑定陷阱

需要特别注意，[[HomeObject]] 是在对象字面量求值阶段静态绑定的。如果将一个使用了 super 的简写方法赋值给另一个新对象，该方法内部的 super 依然会向原定义对象的原型查找，而不会指向新对象的原型：

const parentA = { speak() { return "A"; } };
const childA = {
  speak() { return super.speak(); }
};
Object.setPrototypeOf(childA, parentA);

const parentB = { speak() { return "B"; } };
const childB = {
  speak: childA.speak // 借用 childA 的方法
};
Object.setPrototypeOf(childB, parentB);

console.log(childB.speak()); // 输出依然是 "A"！因为其 [[HomeObject]] 牢固绑定在 childA 上

总结与选型指南

在现代 JavaScript 规范与工程实践中，对象字面量方法简写语法已经成为绝对的标准范式。在面对不同的函数声明场景时，可以参考以下决策路径进行技术选型：

图 5：在对象中定义方法的场景选型与决策决策树

• 默认推荐：只要是在对象字面量内部定义常规执行函数，无论同步、异步、生成器还是 Getter/Setter，一律优先使用方法简写语法。它更精炼、杜绝无用的原型对象开销、同时原生赋予了原型链委派能力。
• 使用箭头函数属性：仅在明确需要函数“捕获外层作用域的 this”（例如防范作为高阶回调传递时丢失父级上下文）时，才选择将箭头函数作为属性值。
• 使用构造函数或 Class：若该逻辑需要作为类型模板并通过 new 批量生产实例，应直接编写独立的 class 声明，而非将其塞入普通对象字面量中。