又一种无括号调用函数的技巧

在编程语言的世界里，函数调用几乎总是和括号绑定在一起。foo()、bar(1, 2) 这样的写法早已成为条件反射。但总有人在琢磨：能不能不写括号，也能把函数跑起来？近期在 Hacker News 上引发讨论的一个话题，正是围绕这个看似冷门却颇具趣味的问题展开。

无括号调用为什么值得关注

无括号调用函数并不是什么新鲜需求。在 JavaScript 中，标签模板（tagged template）就是一个典型例子：fn\hello`本质上是fn(['hello'])` 的语法糖。这种写法被 styled-components 等库发扬光大，也让人意识到——括号并非调用函数的唯一入口。

据 Hacker News 讨论帖的标题「Yet another way to invoke functions without parentheses」来看，作者提出的是又一种新的思路。它之所以值得关注，不只是因为语法上的猎奇，更因为它触及了一个底层问题：语言通过哪些机制把「某个值」和「可执行行为」连接起来。理解了这些机制，Babel 插件、DSL 设计乃至新兴语言的编译原理都会变得更容易上手。

已知的几类无括号调用方式

在讨论新方法之前，有必要先梳理已有的套路，这样才能看清这个新技巧的位置。

隐式类型转换与 toString

当一个对象被用于需要字符串的上下文，JavaScript 会尝试调用它的 toString 或 valueOf。如果把函数挂在 toString 上，它就会在字符串拼接、模板字符串等场景里被触发。这是一种典型的「副作用式调用」——你并不显式地调用函数，而是让引擎替你调用。

valueOf 与 toString 的触发优先级并不固定，取决于上下文期望的类型。当对象被用于算术运算（如 +、-）时，引擎优先调用 valueOf；而当它被插入字符串模板或用于 String() 转换时，则优先调用 toString。若 valueOf 返回的仍是对象而非原始值，引擎会退而调用 toString。这一顺序由规范中的 ToPrimitive 抽象操作定义，可通过 Symbol.toPrimitive 覆盖。理解这一优先级，是判断某个无括号调用技巧在何种表达式下会被触发的前提。

getter 与属性访问

对象属性的 getter 也是常见手段。定义 get foo() 之后，读取 obj.foo 就会执行一段代码，且不需要一对括号。Vue 3 的响应式系统、以及很多代理（Proxy）技巧都依赖这一机制。

Proxy 是 ES6 引入的元编程设施，允许你拦截目标对象上的基本操作，包括 get、set、has、apply 等。与普通 getter 只能定义在具体属性上不同，Proxy 的 get 陷阱可以拦截任意属性名的读取，并在其中执行任意代码。这意味着你可以创建一个对象，使得对它的任何属性访问都触发同一个函数。当这个函数返回另一个 Proxy 或类似可调用结构时，便能形成一种链式、无需括号的调用形态。这也是许多无括号调用技巧的核心构件。

模板标签与 Symbol.toPrimitive

ES6 引入的模板标签让 fn\...`成为一等公民，而Symbol.toPrimitive` 则提供了比 toString 更底层的类型转换钩子。这两者结合起来，可以构造出相当灵活的无括号调用形态。

上述方法各有限制：有的依赖类型转换时机，有的需要借助运算。而真正让人好奇的，是能否找到一种更「纯粹」、更接近普通调用语义的方式。

这个新方法的思路解析

据 B站以及 YouTube 上多位技术 UP 主的拆解思路来看，新方法的核心并不在于发明某种骇人听闻的语法，而是利用了语言规范中一处长期被忽视的角落。

规范里的隐藏钩子

JavaScript 的规范文档（ECMA-262）中定义了大量内部方法，例如 [[Call]]、[[Get]]、[[HasProperty]] 等。当我们写下 foo() 时，引擎执行的是 [[Call]]。但如果某个操作会间接触发 [[Call]]，理论上就存在绕过括号的可能。

多源分析中，不同来源对于「究竟是哪条规范路径被利用」的说法并不完全一致。有分析者倾向于认为关键在于属性访问配合函数代理，另有来源则强调是某种运算触发了隐式调用。可以确定的是，这类技巧通常需要借助 Proxy 或 Symbol.toPrimitive 之类的元编程设施。

ECMA-262 中的「内部方法」是描述对象运行时行为的抽象规格，不直接暴露给 JavaScript 代码。常见的包括：[[Call]]（函数调用时执行）、[[Construct]]（new 时执行）、[[Get]]（读取属性）、[[GetPrototypeOf]]、[[HasProperty]] 等。普通对象默认不具备 [[Call]]，只有函数对象才有。但 Proxy 可以拦截并自定义 [[Call]]（通过 apply 陷阱）和 [[Get]]（通过 get 陷阱），从而让一个非函数对象在外观上「可调用」，或在属性读取时触发执行。无括号调用的各种技巧，本质上都是在寻找一条能间接触发 [[Call]] 或等效副作用的规范路径。

与已有方案的差异

与标签模板那种「一眼可见」的语法不同，新方法往往更隐蔽，也更依赖运行环境。优点是它可以嵌入到普通表达式中，不需要额外的模板字面量；缺点是它高度依赖实现细节，可读性往往成问题。

需要说明的是，以上关于机制的细节来自对多个来源的交叉比对，其中部分结论为单一来源的推断，读者在实际使用时最好以规范文档和现代引擎行为为准。

这类技巧什么时候值得用

坦率地说，把函数调用写得没有括号，在绝大多数生产代码里都不是好主意。它的价值更多体现在几个特定场景。

构建 DSL 与领域语言

当你希望业务方写出接近自然语言的表达式，例如 用户.下单 就能触发一个动作，getter 和代理就能派上用场。这类设计在测试框架、状态管理库中并不罕见。

教学与原理验证

理解无括号调用，本质上是理解语言如何把「取值」和「执行」这两件事纠缠在一起。对想深入 ES 规范、想写 Babel 插件或自研解释器的人来说，这是一个极好的练手题目。

需要谨慎的边界

在团队协作的代码库里滥用这类技巧，会显著提高维护成本。代码首先是要给人看的，其次才是给引擎执行的。想清楚收益与代价，再决定是否引入。

总的来说，又一种无括号调用函数的思路，与其说是实用工具，不如说是一面镜子，照出了 JavaScript 元编程能力的深度。它提醒我们：语法只是表层，真正决定程序行为的是规范里的那些内部方法。对这类话题感兴趣的读者，不妨顺着 Hacker News 的评论区继续挖下去，那里往往藏着比正文更精彩的细节。