在编译过程中，“类型检查”属于 **语义分析** 阶段

在编译过程中，“类型检查”属于 语义分析 阶段。

✅ 正确答案：C. 语义分析

解释：

• 词法分析：将源代码分解为单词（token），如标识符、关键字、运算符等；不涉及类型。
• 语法分析：根据文法规则构建语法树（parse tree），检查结构是否合法（如括号匹配、语句形式）；仍不检查类型是否兼容。
• 语义分析：在语法正确的前提下，检查程序的含义是否合理，包括：变量是否已声明、类型是否匹配（如 int x = "hello"; 是类型错误）、函数调用参数个数与类型是否正确、作用域规则等。类型检查是其核心任务之一。
• 代码优化：在中间代码或目标代码层面提升效率，与类型正确性无关。

编译阶段简记：
词法 → 语法 → 语义 → 中间代码生成 → 优化 → 目标代码生成
                ↑
           类型检查在此处

类型检查不能放在语法分析阶段完成，根本原因在于：语法分析只关注程序的“结构是否符合文法规则”，而类型检查依赖于程序的“含义和上下文信息”，这些在语法分析阶段尚未建立或不可获取。

具体原因如下：

1. 语法分析无符号表（Symbol Table）
   语法分析器（parser）仅根据产生式规则识别语句结构（如 if (E) S），不记录变量名、类型、作用域等信息。而类型检查必须知道：

   • 变量 x 是否已声明？
   • 它的类型是 int 还是 float？
   • 在嵌套作用域中，同名变量是否遮蔽（shadowing）？
     这些需依赖语义分析阶段构建并查询的符号表，语法分析阶段尚未构建。

2. 类型依赖于语义上下文，而非纯语法形式
   例如：

   int a = b + c;
   

   语法上完全合法（b + c 是表达式，= 是赋值），但能否通过类型检查，取决于 b 和 c 的实际声明类型（如 b 是 char*、c 是 int，则 + 可能非法）。这种判断超出了 BNF 或 CFG 的表达能力——语法分析器无法区分 int+int 与 char*+int，因为它们具有相同语法结构。

3. 类型规则是非上下文无关的（Context-Sensitive）
   典型例子：C语言中数组下标必须是整型，但语法上 a[b] 中 b 可以是任意表达式；类型检查需验证 b 的类型是否属于整型族（int, long, size_t 等），这涉及类型继承、隐式转换、用户定义类型等复杂规则，无法用上下文无关文法（CFG）描述，因此不属于语法分析职责。

4. 阶段分离是编译器工程最佳实践
   将“结构验证”（语法）与“含义验证”（语义）解耦，提高模块化、可维护性和可扩展性。例如：支持泛型、重载或多态的语言，其类型检查逻辑极为复杂，若混入语法分析，会使 parser 耦合过重、难以测试和复用。

✅ 总结：
语法分析回答 “这串字符是否构成一个合法的 if 语句？”
语义分析（含类型检查）回答 “这个 if 语句中的所有变量是否已正确定义？条件表达式的类型是否为布尔可转换？分支中的赋值是否类型兼容？”