为什么JavaScript示例代码总用foo和bar

在阅读 JavaScript 技术文档、MDN Web 文档、ECMAScript 语言规范或各类教程时，你几乎不可避免地会遇到 function foo() 或 let bar = 123 这样的写法。示例代码之所以普遍使用 foo 和 bar，核心原因在于它们是编程领域的“元语法变量”（Metasyntactic Variables）：它们没有任何具体的业务含义，能够彻底剥离具体应用场景的噪音，强制读者的注意力聚焦于纯粹的语法规则、控制流向和底层运作机制本身。

一、什么是元语法变量：关注点隔离与认知减负

在数学和代数中，当我们想推导乘法分配律时，会写下 a * (b + c) = a * b + a * c，而不会写成“苹果数 * (香蕉数 + 橘子数)”。代数符号 a、b、c 不代表具体的现实水果，而是纯粹的数值占位符。编程中的 foo 和 bar 起到的正是完全相同的作用。

如果作者在讲解 JavaScript 高阶函数时使用了真实的业务变量：

// 带有具体业务色彩的示例
function processUserOrder(order, callback) {
  const verifiedOrder = validatePaymentStatus(order);
  callback(verifiedOrder);
}

读者的潜意识会不由自主地产生一系列与语法无关的业务疑问：“order 里面有哪些必填字段？”、“validatePaymentStatus 是异步校验还是同步校验？”、“如果支付失败会不会抛出错误？”这些联想分散了理解核心语法的心智资源。反之，如果换成抽象占位符：

// 使用元语法变量的纯粹语法示例
function foo(bar, callback) {
  const baz = bar + 1;
  callback(baz);
}

此时任何人都清楚：foo、bar 和 baz 没有任何数据库模型或业务实体对应物，所有注意力立刻集中在“回调函数的接收与调用执行时机”这一个核心机制上。

二、追根溯源：foo 与 bar 的历史演化与标准化

为什么偏偏是这两个音节，而不是其他单词？这背后有着长达半个多世纪的工程文化积淀：

1. 二战军事俚语 FUBAR：最早可追溯至第二次世界大战期间美军通信兵的行话 FUBAR（“Fouled Up Beyond All Recognition”，意指现场陷入彻底混乱）。战后，进入麻省理工学院（MIT）等科研机构的雷达与无线电工程师将这一词汇带入了早期的计算机黑客圈子。
2. 拆解为 foo 与 bar：在 1960 至 1970 年代，MIT 人工智能实验室（AI Lab）基于 PDP-6/PDP-10 计算机开发 ITS 系统时，黑客们将 FUBAR 拆分成了双音节词汇 foo 与 bar，用来命名临时文件、未知寄存器和测试变量。
3. 互联网工程任务组 RFC 3092 规范：2001 年，IETF 发布了具有幽默色彩但广受认可的官方信息型文件 RFC 3092《Internet 说明书中的元语法变量词源》，正式确定了标准的技术示例变量派生序列：

   foo -> bar -> baz -> qux -> quux -> corge -> grault -> garply -> waldo -> fred -> plugh -> xyzzy -> thud

4. 从 C/Unix 社区渗透至 JavaScript：早期的 Netscape 工程师、Brendan Eich 以及后续编写 ECMAScript 标准草案和各大浏览器引擎核心的开发者，大多深受 Unix 与 C/C++ 黑客文化浸润。当 JavaScript 在 1995 年诞生并逐步繁荣后，这一命名习惯自然而然地被带入到语言规范与教程体系中。

三、JavaScript 典型教学场景中的具体运用

在 JavaScript 的核心语言教学中，有几类特定语法极度依赖 foo 与 bar 的抽象特性：

1. 解构赋值与重命名语法

在演示 ES6 对象解构与变量别名赋值时，使用 foo 和 bar 能够最直观地展现“左边是源对象属性名，右边是新建的本地变量”：

const obj = { foo: '数据内容' };

// 把属性 foo 的值取出，并赋给新声明的局部变量 bar
const { foo: bar } = obj;

console.log(bar); // 输出: 数据内容

如果这里使用 userName: nickname，初学者常常会困惑到底哪个是原本就存在的字段，哪个是新声明的变量。而 foo: bar 遵循标准的先后序列，一眼即可看出属性到变量的映射流向。

2. 原型继承与方法覆盖（Prototype Chain）

讲解原型链查找规则时，使用具体动物（如 Animal/Dog）往往会引发“狗到底应不应该继承叫声”等面向对象建模合理性的争议，而技术重点其实在于指针链接：

function Foo(name) {
  this.name = name;
}

Foo.prototype.bar = function() {
  return `调用来自原型方法: ${this.name}`;
};

const baz = new Foo('实例对象');
console.log(baz.bar());

3. 柯里化与高阶函数的闭包特性

高阶函数关注的是“函数的返回与调用”，与参数具体是什么数据类型无关：

// 纯粹展示柯里化结构
const foo = (x) => (y) => x + y;
const bar = foo(5);
console.log(bar(10)); // 输出: 15

四、示例代码的命名决策流程

虽然 foo 和 bar 非常便利，但并非所有示例代码都应套用它们。编写示例或技术文章时，可以通过以下决策流程来准确选取命名策略：

五、适用边界与禁忌：何时绝不能使用？

元语法变量虽然在语言规范和极简教学中不可或缺，但在实际开发与生产代码中，它们属于明确的代码坏味道（Code Smell）。

代码场景	是否推荐使用	核心原因说明
语法规范 / 语言特性文章	完全推荐	专注于语言特性（如尾调用优化、解构赋值），无业务歧义。
提报 Bug 的最小复现 Demo (MRE)	强烈推荐	在 GitHub Issue 或 Stack Overflow 上剔除所有私有业务代码，极简排查。
单元测试哑数据 (Mock / Stub)	视情况推荐	当测试断言仅需证明某参数原样传递、不关心内容时可用。
项目业务代码 / 公共库 API	严禁使用	极度破坏可读性，破坏团队协作与 TypeScript 类型提示的直观性。
面向初学者的框架实战项目	不建议使用	初学者难以将 foo 映射到真实开发中的业务模型，应使用 todoList、cartItem。

六、知识全景总结

总结来说，JavaScript 示例代码中频繁出现的 foo 与 bar，既是计算机黑客文化历史沉淀下来的约定俗成，也是现代技术写作中“关注点分离”的高效工具。它让示例代码化繁为简，帮助读者在最短时间内穿透代码表层，直达语言的核心逻辑。