你写过 let x = a + b 这样的代码吗？它背后到底在算什么？
先别急着翻文档——咱们一起拆开看：当你敲下这一行，JavaScript 其实正在悄悄判断哪一部分才是整个表达式的“主心骨”。这个“主心骨”，就是 `primary-expression`。
那问题来了：
- *primary-expression 是什么意思？它真有那么重要吗？**
简单说：它是 JavaScript 语法里最基础、不可再拆分的表达式单元。就像造房子的砖块——你不能把一块砖再切成半块去当“结构单位”，它本身就是最小承重单元。
# 那哪些东西算 primary-expression？举几个新手一眼就懂的例子：
- 字面量：`42`、`”hello”`、`true`、`null`、`[1,2,3]`、`{a:1}`
- 变量名：`count`、`userName`、`API_URL`（只要它已经声明过）
- 空括号组：`( )` —— 对，空括号也是！它代表一个空表达式，合法且常用
- 函数调用：`alert()`、`Math.max(1,2)`、`fetch(url).then(…)`
- 类实例化：`new Date()`、`new Map()`
? 关键特征：它自己就能独立求值，不需要依赖其他操作符来“撑场子”。
? 不是 primary-expression 的：`a + b`（需要 `+`）、`!flag`（需要 `!`）、`x ? y : z`（需要三元符号）——它们都属于更上层的表达式类型。
# 为什么非得搞懂它？不就是个语法术语吗？
说实话，刚学 JS 时我也觉得：“反正能跑就行，管它叫啥？”
但后来写了一个 bug 花了两小时才定位——起因就是混淆了 `obj.method()`（primary）和 `(obj.method)()`（看着像，其实加括号后改变了 this 绑定逻辑，而括号本身属于 grouping operator，不是 primary）。
这时候才明白：理解 primary-expression，等于拿到了 JS 表达式解析顺序的“地图起点”。
比如这段代码：
“`js
foo().bar[0].toString()
“`
JS 是怎么一步步执行的？
→ 先算 `foo()`（primary）
→ 再取 `.bar`（member access，基于前一步结果）
→ 再取 `[0]`（property access）
→ 最后调用 `.toString()`（call expression）
所有链条，都是从一个 primary-expression 开始“滚雪球”的。
# 实际场景中，它在哪悄悄影响你的日常开发？
我们来看三个真实小片段：
?? 场景1：模板字符串里的插值
“`js
const name = “小明”;
console.log(`欢迎${name}回来`); // ${name} 位置必须填一个 primary-expression
// ? 可以：${name}、${getName()}、${users[0]}
// ? 不行：${a + b} —— 错！等等，其实可以？对，但注意：a + b 整体是 additive-expression，不是 primary；
// 而 `${}` 内部允许的是 *expression*（广义），不是 strict primary —— 所以这里容易混淆。
“`
?? 这说明：规范术语和实际编码约束不是完全一一对应的。primary-expression 是底层文法基石，但开发者接触更多是上层语法规则。知道它，是为了不被“好像能跑”骗过去。
?? 场景2：箭头函数的隐式返回
“`js
const double = x => x * 2; // ? 没大括号 → 自动 return 一个 primary-expression（x*2 是乘法表达式，不是 primary）
const getObj = () => ({ id: 1 }); // ? 注意：({}) 外层括号是 grouping，内部 {} 是 object literal → primary！
const bad = () => { id: 1 }; // ? 这是代码块，不是对象字面量！会返回 undefined
“`
看到没？少一对括号，结果天差地别——而根源，就在 `{}` 是不是作为 primary-expression 出现。
?? 场景3：动态 import()
“`js
import(`./modules/${lang}.js`) // ? import() 是 call expression，其参数必须是 primary（这里是模板字面量）
“`
如果传了个 `a + ‘.js’`？也能跑。但它的“根”还是 `a`（primary）和 `’.js’`（primary）——中间的 `+` 是粘合剂，不是主角。
# 给新手的一句实在话：
你不用背定义，也不用明天就去读 ECMAScript 标准第 12.2 节。
但当你某天看到报错 `Unexpected token ‘}’` 或 `Cannot read property ‘xxx’ of undefined`，而代码看起来“明明没问题”，
不妨停下来问一句：
→ “我这儿最开头那个能独立求值的东西，真的是 primary 吗？”
→ “它有没有被括号/点号/方括号‘带偏’，其实已经不是原始形态了？”
这种习惯，比死记硬背有用十倍。
我自己踩过最多次的坑，是把 `function foo(){}` 当作 primary-expression 直接传参（忘了加括号调用或包一层 `()`），结果传进去的是函数定义本身，而不是执行结果……哎，都是泪。
所以啊，primary-expression 不是考题，是调试时的一个思维锚点——锚定了，后面一串链路就清晰了。
你最近一次遇到“明明该有值却 undefined”的情况，是在哪个环节？欢迎聊聊，说不定我们能一起揪出那个藏起来的 non-primary “冒牌货”。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
