开头先问你一个事儿：
你有没有试过写模板函数，结果编译器突然报错，说“无法推导类型”？
明明参数都传了，它却像没看见一样——这时候，可能不是你代码错了，而是primary-expression这个概念悄悄挡了路。
别慌，今天咱们就掰开揉碎讲清楚：它到底是什么？为什么它会和模板推导“扯上关系”？而且，还是在C++17这个关键版本里“升级”了角色。
什么是primary-expression？
先说人话：primary-expression是C++语法里最基础、不能再拆的表达式单元。
就像英语里的“单词”，不是词组，也不是句子——它是整个表达式大厦的地基。
常见的 primary-expression 包括：
- 字面量（比如 `42`、`3.14`、`true`）
- 标识符（比如变量名 `x`、函数名 `foo`）
- 圆括号包起来的表达式（比如 `(a + b)`——注意：括号本身不改变语义，只是分组）
- `this` 指针、lambda 表达式（C++11起）、字符串字面量等等
?? 关键点来了：它不能是运算符表达式本身。比如 `a + b` 是二元表达式，不是 primary-expression；但 `a` 是，`b` 是，`(a + b)` 也是（因为加了括号，就成了“带括号的表达式”，属于 primary-expression 的一种）。
那它跟模板参数推导有啥关系？
这就得说到 C++17 的一个悄悄变化：模板实参推导规则加强了对 primary-expression 的依赖。
举个真实例子??
“`cpp
template
void func(T&& x) { }
int main() {
int a = 10;
func(a); // 推导 T = int&
func(42); // 推导 T = int
func(a + 5); // 推导 T = int（没问题）
func((a + 5)); // 推导 T = int（也没问题）
}
“`
看起来都一样？但如果你换成类模板参数推导（CTAD），差别就露出来了：
“`cpp
template
struct Box { T val; };
Box b1{42}; // OK：42 是 primary-expression → T = int
Box b2{a + 5}; // ? 错误！C++17 要求 CTAD 的初始化器必须是 primary-expression
// 而 a+5 是二元表达式，不满足条件
“`
你看，不是所有“能算出值”的东西，都能进模板推导的“VIP通道”。C++17 明确划了一条线：只有 primary-expression 才能直接用于类模板自动推导。这是为了保证推导行为更可预测、更少歧义。
为什么设计成这样？我的一点看法
我刚学的时候也纳闷：不就是算个值吗？干嘛卡得这么细？
后来写多了泛型库才明白——编译器需要“稳”。如果允许任意复杂表达式参与推导，比如 `func(f(g(x)) + h(y))`，那类型推导可能要回溯好几层，既慢又容易产生意外绑定（比如把引用套太多层）。
而 primary-expression 天然简单、无副作用、结构明确，相当于给编译器发了个“干净输入卡”。这不是限制，是给新手一条清晰的路：你想让模板猜对，就尽量用最直白的输入。
顺便说一句：这规则对初学者其实很友好。你只要记住——
? 用变量名、数字、字符串、带括号的表达式，基本稳；
? 少用带运算符的裸表达式（如 `x+y`, `*ptr`, `arr[i]`）直接进 CTAD。
再来个生活化类比
想象你在教朋友做菜：“把盐、糖、酱油倒进锅里”。
如果他说：“把昨天剩的红烧肉汁+半勺醋+碾碎的蒜末混进去”——你得先确认他是不是真知道每样东西的状态（凉的？热的？有没变质？），再决定火候怎么调。
但如果说：“放一勺盐”，你立刻就能动手。
- *primary-expression 就是那一勺盐——确定、独立、无需上下文解释。**
最后一句大实话
别被术语吓住。“primary-expression”听着高冷，其实就两件事：
- 它是语法最小单位，不是“组合体”；
- 在 C++17 类模板推导里，它成了“准入门槛”。
你不用背所有语法分类，只要写模板时多想一秒：“我传进去的这个东西，是不是一眼就能看出类型？”——如果是，大概率它就是 primary-expression。
我自己现在写 CTAD，习惯先写个临时变量存中间结果，再传进去。不是偷懒，是让代码更“可读、可猜、可维护”。毕竟，编程不是考编译器智商，是让人和机器一起把事情办妥。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
