跳到主要内容

编译原理热门面试题

使用说明​

本篇共 45 道题。

编译原理题对前端岗位主要考查 AST、Babel、静态分析和工具链理解。回答能串起数据结构与阶段，比背算法名更重要。

Q1: 编译器的主要阶段有哪些？​

答案：

典型流程是词法分析把字符转 Token，语法分析生成 AST，语义分析检查名称和类型等约束，再转换/优化中间表示并生成目标代码。

不同编译器会合并或增加阶段。前端 Babel 主要做源码到源码转换，不一定执行完整类型检查和机器码生成。

  • 典型流程是词法分析得到 Token、语法分析生成 AST、语义分析检查类型和作用域，再转换 IR、优化并生成目标代码。
  • 现代工具可能只做其中一部分，例如 Babel 主要解析、转换和生成 JavaScript；各阶段通过清晰 IR 解耦，错误信息保留源码位置。

Q2: 词法分析和语法分析有什么区别？​

答案：

词法分析识别关键字、标识符、数字和符号等 Token；语法分析根据文法把 Token 组织成有层级的程序结构。

例如 const x = 1 先拆成 Token，再形成变量声明 AST。词法错误和语法错误发生在不同层。

  • 词法分析按字符规则识别标识符、数字、关键字和运算符；语法分析再按文法把 Token 组合成表达式、语句和声明。
  • let x = 可以成功分词却无法形成完整语法树。两阶段分开能简化规则，也让错误定位更准确。

Q3: 什么是 AST？​

答案：

AST（Abstract Syntax Tree）是源代码的树状结构化表示，去掉了空白、注释等无关信息，保留语法结构。

前端应用场景：

  • 代码转译：Babel（ES6→ES5）、TypeScript（TS→JS）
  • 代码检查：ESLint 规则基于 AST 分析
  • 代码格式化：Prettier 解析后重新输出
  • 代码压缩：Terser 分析 AST 做变量名压缩、死代码删除
  • 模块分析：Webpack 分析 import/require 构建依赖图
  • 自动重构：Codemod 批量修改代码
  • IDE 功能：代码补全、跳转、重命名

Q4: AST 和 CST 有什么区别？​

答案：

CST 更完整保留文法产生式、括号和标点，适合需要高保真源码的工具；AST 抽象掉部分语法细节，更适合语义分析和转换。

格式化器和 IDE 常需要保留注释、空白或 Token 信息，可能使用 CST 或增强 AST。

  • CST 保留括号、分号等全部语法细节，适合格式化、无损重写；AST 去掉很多冗余节点，更突出程序语义，适合编译和静态分析。
  • 同一源码可对应不同抽象程度的树。选择取决于是否必须原样还原注释与格式，不能简单说 AST 永远更好。

Q5: 什么是语义分析？​

答案：

它检查语法正确后仍可能错误的规则，例如变量是否声明、作用域绑定、类型是否兼容、break 是否出现在合法位置。

通常会建立符号表和作用域信息。语法树看起来合法，不代表程序语义合法。

  • 语义分析处理“语法合法但含义错误”的情况，例如未声明变量、重复声明、类型不兼容和错误的 break 位置。
  • 它通常建立符号表、解析作用域和类型，并把结果标注到 AST/IR；错误应带源码区间和上下文，便于一次报告多个问题。

Q6: 中间表示（IR）有什么价值？​

答案：

IR 把源语言和目标平台之间解耦，让多个前端语言共享优化和后端，也让控制流和数据流分析更容易。

IR 可以有多层，从接近源码到接近机器。前端工具不一定显式暴露 IR，但概念同样用于规范化转换。

  • IR 把源语言细节转换成更统一的表示，让优化不必直接操作复杂语法，也让一个前端可以复用多个目标后端。
  • 高层 IR 保留对象或控制结构，低层 IR 更接近机器指令；真实编译器常在多级 IR 间逐步 lowering。

Q7: 编译器常见优化有哪些？​

答案：

常量折叠、死代码删除、公共子表达式消除、内联、循环优化和寄存器分配等。优化必须保持可观察语义。

动态语言还要依赖运行时类型反馈和去优化。优化不是越激进越好，还要权衡编译时间、代码体积和调试能力。

  • 常见优化包括常量折叠/传播、死代码删除、公共子表达式消除、函数内联、循环优化和寄存器分配。
  • 前提是保持语言的可观察语义，特别要谨慎处理副作用、异常、浮点和并发。优化效果应通过基准与代码尺寸共同验证。

Q8: 解释执行和编译执行有什么区别？​

答案：

解释器边读取表示边执行，启动快、实现灵活；提前编译先生成目标代码，运行快但构建有成本。现代 JavaScript 引擎通常解释、基线编译和优化 JIT 混合。

JIT 根据热点和类型反馈优化，假设失效时去优化，因此代码性能与真实运行模式相关。

Q9: Babel 的解析、转换和生成分别做什么？​

答案：

Parser 把源码转 AST；插件 Visitor 遍历并修改 AST；Generator 把 AST 输出为代码和 Source Map。

Preset 组合多个插件。转换语法后仍要根据目标环境处理运行时 API 和 helper 去重。

Q10: Babel Visitor 为什么使用进入/离开节点的模型？​

答案：

树遍历到节点时可在 enter 处理，遍历完子节点后在 exit 处理，适合需要前序或后序信息的转换。

修改树时要使用框架提供的 Path API 管理作用域、替换和重新遍历，直接改普通对象容易破坏不变量。

  • 进入回调适合自顶向下建立作用域或在处理子节点前改写；离开回调在子节点处理完后执行，适合聚合结果和后序变换。
  • 插件修改树时要理解遍历器是否会重新访问新节点，并用 path 的 replace/skip/stop 控制，否则容易重复转换或无限遍历。

Q11: Babel 插件如何避免变量名冲突？​

答案：

不能手写一个看似唯一的名字，应使用作用域 API 生成 UID、查询绑定并在正确 Scope 中插入声明。

还要区分引用和同名属性、标签或字符串。Scope/Binder 是可靠代码转换的关键。

  • 不能只拼接一个看似没用过的名字，因为外层或闭包里可能同名。应通过作用域对象查询绑定，并使用 generateUidIdentifier 等 API 生成唯一标识。
  • 重命名还要更新该 binding 的所有引用，同时避开属性名、标签和不同命名空间，保持源码语义。

Q12: Source Map 记录什么？​

答案：

它把生成代码的行列位置映射回原始文件位置，并可包含符号名和源码内容，供调试器和错误平台还原堆栈。

多阶段构建需要正确串联合并映射，否则最终位置会偏。生产还要控制源码公开风险。

  • Source Map 的 mappings 把生成文件的行列关联到原文件、原行列和可选符号名，通常用 Base64 VLQ 压缩。
  • 多阶段构建要正确串联合并每一层 Map；监控平台还必须按 release 匹配产物，否则会把线上堆栈还原到错误源码。

Q13: 如何实现一个简单表达式编译器？​

答案：

定义 Token 和文法，Lexer 输出 Token，Parser 按优先级/结合性生成 AST，遍历 AST 做检查或转换，最后解释执行或生成目标代码。

先支持少量语法并加入位置和错误恢复，再扩展；测试要覆盖合法输入、边界和明确错误信息。

Q14: 静态分析工具为什么可能误报？​

答案：

静态分析只能基于可见代码和抽象模型推断，动态导入、反射、运行时配置和跨语言边界会让信息不完整。

规则应给出证据和可配置边界，严重问题尽量提高精度；自动修复必须保证语义或限制在安全变换。

  • 静态分析只能根据代码和模型做近似，动态属性、反射、条件加载和外部数据会让工具无法确定真实运行路径。
  • 为保证安全，有的规则倾向多报；为减少噪音，有的规则会漏报。规则应支持精确抑制、严重级别和项目上下文，而不是让团队习惯全局关闭。

Q15: 增量编译如何提高速度？​

答案：

缓存文件解析、依赖图和阶段结果，只对变化文件及受影响下游重新计算，并用内容/配置哈希判断缓存有效性。

难点是依赖失效准确性、全局类型变化和插件副作用。错误缓存比全量慢更危险，因此要有一致性校验和回退。

  • 增量编译缓存文件解析结果和依赖图，只重新处理变化文件及其受影响消费者；内容哈希和稳定配置决定缓存能否复用。
  • 接口未变化时可避免级联重编译。还要正确处理删除、配置变化、插件版本和跨包引用，否则“快”会以陈旧产物为代价。

Q16: Babel 中 Plugin 和 Preset 的执行顺序怎么理解？​

答案：

Preset 本质上是一组配置和插件。Babel 配置合并后，Plugin 通常先于 Preset 中的插件执行；Preset 的应用顺序通常与声明顺序相反，而每个 Plugin 的 visitor 还可能在节点进入和退出阶段执行。

不能只背一句“从右到左”，因为继承配置、overrides、env、插件自身 visitor 和多次遍历都会影响实际行为。排查时应查看某文件最终生效的配置，为关键输入输出写最小转换测试，并明确插件期望处理原始语法还是另一插件生成的语法。

顺序错误常表现为节点已经被删除、重复包装或 Source Map 位置异常。

Q17: 如何编写一个 Babel 插件？​

答案：

Babel 插件是一个返回对象的函数，核心是 visitor：

// 插件：将 == 替换为 ===
export default function strictEqualPlugin(): PluginObj {
  return {
    name: 'strict-equal',
    visitor: {
      BinaryExpression(path) {
        if (path.node.operator === '==') {
          path.node.operator = '===';
        }
        if (path.node.operator === '!=') {
          path.node.operator = '!==';
        }
      },
    },
  };
}

// 配置 babel.config.js
// { plugins: ['./plugins/strict-equal'] }

开发流程：

  1. 在 AST Explorer 观察目标代码的 AST 结构
  2. 确定要处理的节点类型
  3. 编写 visitor 方法
  4. 用 @babel/types 构建新节点
  5. 测试：@babel/core 的 transformSync 方法验证

Q18: 递归下降解析如何处理运算符优先级？​

答案：

通过语法规则的分层实现。每一层只处理同优先级的运算符：

expression = term (('+' | '-') term)*     ← 低优先级
term       = factor (('*' | '/') factor)* ← 高优先级
factor     = NUMBER | '(' expression ')'  ← 最高（括号）
  • 先解析子节点（高优先级），再组合（低优先级）
  • 2 + 3 * 4 先解析 3 * 4 得到节点，再和 2 做 +
  • 括号通过递归回到顶层规则，强制提升优先级

Q19: AST 在前端工程中有哪些应用场景？​

答案：

AST 把源码转换为带类型和层级关系的结构，工具可以基于语法语义而不是字符串位置进行分析和修改。

常见应用包括：

  • Babel/SWC 等语法转换和 Polyfill 注入。
  • ESLint 静态检查与安全的 Auto Fix。
  • TypeScript 类型分析和声明生成。
  • Tree Shaking、依赖分析与代码分割。
  • Codemod、API 迁移和批量重构。
  • Vue/React 编译器的模板或 JSX 优化。
  • 代码格式化、文档提取和测试覆盖率插桩。

AST 也不是万能的：需要类型信息或控制流时还要结合符号表、作用域和 CFG；自动修改必须保留注释、格式与语义，并通过测试验证。

Q20: ESLint 自定义规则如何实现自动修复（Auto Fix）？​

答案：

在 context.report() 中提供 fix 函数：

const rule: Rule.RuleModule = {
  meta: {
    fixable: 'code', // 必须声明！
  },
  create(context) {
    return {
      Literal(node) {
        if (typeof node.value === 'string' && node.raw?.[0] === '"') {
          context.report({
            node,
            message: '请使用单引号',
            fix(fixer) {
              // fixer 方法：
              // replaceText / replaceTextRange — 替换
              // insertTextBefore / insertTextAfter — 插入
              // remove — 删除
              return fixer.replaceText(node, `'${node.value}'`);
            },
          });
        }
      },
    };
  },
};

注意事项：

  • meta.fixable 必须声明为 'code' 或 'whitespace'
  • fix 函数返回 fixer 操作或操作数组
  • ESLint 会自动处理多次修复的冲突

Q21: 词法分析中的最长匹配原则是什么？​

答案：

当当前位置存在多个可接受 Token 时，词法分析器通常选择能消费字符最多的候选，也叫 maximal munch。例如输入 >= 应识别为一个大于等于运算符，而不是先识别 > 再留下 =。

最长匹配仍需要优先级规则处理相同长度候选。例如关键字 if 与标识符规则都能匹配时，可先识别标识符再查关键字表，或由规则顺序决定。

它不是在整段源码中寻找最长字符串，而是从当前游标决定下一个 Token。字符串、模板、正则等带上下文的语法还可能需要词法状态或解析器提供上下文。

Q22: 访问者模式（Visitor Pattern）在编译器中的作用？​

答案：

访问者模式将 数据结构（AST） 和 操作（转换逻辑） 分离。遍历器负责遍历每个节点，访问者定义对每种节点的处理逻辑：

// 每个 Babel 插件就是一个 Visitor
const myPlugin = {
  visitor: {
    // 当遍历器遇到 Identifier 节点时调用
    Identifier(path) {
      if (path.node.name === 'oldName') {
        path.node.name = 'newName';
      }
    },
    // 可以同时处理多种节点
    'FunctionDeclaration|ArrowFunctionExpression'(path) {
      // 处理所有函数
    },
  },
};

好处：添加新的转换逻辑只需添加新的 Visitor，不需要修改 AST 遍历逻辑。

Q23: @babel/types、@babel/template、@babel/traverse 各自的作用？​

答案：

包作用使用场景
@babel/parser将源代码解析为 AST输入阶段
@babel/traverse遍历 AST，提供 path API访问/修改节点
@babel/typesAST 节点构建与类型判断创建新节点、类型守卫
@babel/template用模板字符串创建 AST 片段构建复杂代码结构
@babel/generatorAST → 源代码字符串输出阶段
import * as t from '@babel/types';
import template from '@babel/template';

// @babel/types: 手动构建节点
const node = t.variableDeclaration('const', [
  t.variableDeclarator(t.identifier('x'), t.numericLiteral(42)),
]);

// @babel/template: 用模板快速构建（更直观）
const buildRequire = template(`
  const %%importName%% = require(%%source%%);
`);

const ast = buildRequire({
  importName: t.identifier('React'),
  source: t.stringLiteral('react'),
});

Q24: 手写 JSON Parser 需要注意什么？​

答案：

  1. 字符串转义：处理 \", \\, \/, \n, \t, \uXXXX 等
  2. 数字格式：负号、小数、科学计数法（1.5e10）
  3. 递归结构：对象和数组可嵌套
  4. 空白处理：键值对之间的空白需跳过
  5. 错误信息：提供有意义的位置信息

Q25: 递归下降解析器的基本原理？​

答案：

递归下降解析是最直观的语法分析方法，每个语法规则（产生式）对应一个递归函数：

// 简化的表达式解析器
// 语法规则：expr = term (('+' | '-') term)*
//           term = factor (('*' | '/') factor)*  
//           factor = NUMBER | '(' expr ')'

class Parser {
  private tokens: Token[];
  private pos = 0;

  parseExpression(): ASTNode {
    let left = this.parseTerm();
    
    while (this.match('+') || this.match('-')) {
      const op = this.previous().value;
      const right = this.parseTerm();
      left = { type: 'BinaryExpression', operator: op, left, right };
    }
    
    return left;
  }

  parseTerm(): ASTNode {
    let left = this.parseFactor();
    
    while (this.match('*') || this.match('/')) {
      const op = this.previous().value;
      const right = this.parseFactor();
      left = { type: 'BinaryExpression', operator: op, left, right };
    }
    
    return left;
  }

  parseFactor(): ASTNode {
    if (this.match('Number')) {
      return { type: 'NumericLiteral', value: Number(this.previous().value) };
    }
    if (this.match('(')) {
      const expr = this.parseExpression();
      this.expect(')');
      return expr;
    }
    throw new SyntaxError('Unexpected token');
  }
}

Q26: Codemod 和手动替换相比有什么优势？​

答案：

维度Codemod（AST）正则/全局替换
准确性理解语法结构，精确匹配可能误匹配注释/字符串
安全性类型感知，不破坏代码可能破坏代码结构
复杂转换支持条件判断、作用域分析难以处理复杂场景
可复用写一次，跑遍全项目每次手动操作
可测试可编写单元测试难以测试

适用场景：框架大版本升级（React class → Hooks）、API 重命名、废弃用法迁移。

Q27: Vue 模板编译和直接字符串拼接有什么区别？​

答案：

Vue 模板编译器做了远比字符串替换更多的事情：

步骤作用
ParseHTML → AST（tag、attribute、directive、事件等）
Transform静态标记（PatchFlag）、静态节点提升、事件缓存
GenerateAST → 渲染函数（createVNode 调用）

关键优化（Vue 3）：

  • 静态提升：纯静态节点只创建一次
  • PatchFlag：标记动态部分，Diff 时只比较变化的属性
  • Block Tree：减少 Diff 范围
  • 缓存事件处理器：避免子组件不必要的更新

Q28: 编译时和运行时的区别？哪些事应该放在编译时？​

答案：

维度编译时运行时
执行时机构建阶段（开发者机器/CI）用户浏览器中
性能影响只影响构建速度影响用户体验
代表Babel、TypeScript、WebpackReact VDOM Diff、Vue Reactivity

应放在编译时的工作：

  • 类型检查（TypeScript）
  • 语法降级（Babel）
  • 模板编译（Vue SFC → render 函数）
  • 静态分析（Tree Shaking、死代码删除）
  • 代码压缩（Terser）
  • CSS 前缀（Autoprefixer）
  • 宏展开（Vite define、import.meta.env）

原则：能在编译时完成的事不要推迟到运行时，减少用户端开销。

Q29: 如何在编译阶段做性能优化？​

答案：

编译时优化的常见手段：

  1. 静态分析与 Tree Shaking：分析 import/export 删除未使用代码
  2. 常量折叠：1 + 2 编译时直接算出 3
  3. 死代码删除：if (false) { ... } 直接移除
  4. 模板预编译：Vue template → render 函数（避免运行时编译）
  5. CSS 原子化：编译时提取原子类（Tailwind、UnoCSS）
  6. 宏替换：process.env.NODE_ENV → "production" 后配合 Tree Shaking
  7. 静态提升：Vue 3 将静态节点提升到渲染函数外部
// Babel 常量折叠示例
// 输入
const x = 1 + 2 + 3;
const y = 'hello' + ' ' + 'world';

// 编译后
const x = 6;
const y = 'hello world';

Q30: AOT 和 JIT 编译分别适合什么场景？​

答案：

AOT 在程序运行前完成主要编译工作，启动路径更可预测，适合发布产物、受限运行环境和希望把错误提前暴露的场景；代价是构建时间、目标平台产物和缺少运行时画像。

JIT 在运行期间根据真实类型和热点路径编译、优化，可以对动态行为做专门化；代价是预热、编译开销、内存占用和可能发生去优化。

现代系统常混合使用：先用解释器或基线代码快速启动，再对热点 JIT；模板和框架代码可在构建期 AOT，而业务 JavaScript 仍由引擎运行时优化。选择要看启动、峰值性能、包体和部署约束。

Q31: 递归下降解析中的 Lookahead 和回溯怎样取舍？​

答案：

Lookahead 先查看一个或少量 Token，再决定进入哪条产生式；文法分支能用有限前瞻区分时，解析器可以保持线性、错误也更明确。

回溯会先尝试一条分支，失败后恢复 Token 位置再尝试另一条。它实现简单，但嵌套分支可能造成指数级尝试，并让错误位置难以解释。

工程中通常优先改写文法、提取左公因子或使用 Pratt/优先级爬升处理表达式，减少任意回溯。若必须回溯，要保存解析状态、限制范围并缓存结果。

Q32: 什么是左递归？为什么递归下降解析器不能直接处理？​

答案：

左递归是产生式右侧一开始又出现自身，例如 Expr -> Expr + Term。递归下降如果直接照着实现，会在还没消费任何 Token 时不断调用自己，最终栈溢出。

常见处理方式是消除左递归，把规则改写成“先解析一个基础项，再循环解析后续运算符和项”。这样既能终止，也方便表达左结合。

Q33: 解析器怎样报告有用的语法错误位置？​

答案：

Lexer 应为 Token 保留起止 offset 和可映射的行列信息；Parser 在失败时记录实际 Token、期望集合和所在语法上下文，而不是只抛“syntax error”。

高质量错误通常包括：

  • 精确源码范围和带插入符号的代码片段。
  • 期望与实际内容，例如“参数列表后期望右括号，实际得到左花括号”。
  • 对常见错误给出可行动建议，但不在不确定时误导。
  • 恢复后继续收集有限数量错误，避免第一个问题阻塞全部反馈。

源码经过多阶段转换时，还要通过 Source Map 或位置映射回用户文件。

Q34: Pratt Parser 适合解决什么问题？​

答案：

Pratt Parser 适合解析包含大量一元、二元、后缀运算符的表达式。它通过每个 Token 的前缀解析函数、后缀解析函数和绑定强度统一处理优先级。

相比为每一级优先级写一个函数，它更容易扩展新运算符；代价是初次理解和错误恢复更复杂，适合表达式丰富的语言或 DSL。

Q35: 编译器中的符号表保存什么信息？​

答案：

符号表记录标识符与其声明信息的映射，例如名称、类型、作用域、存储位置和可见性。

  • 进入新作用域时创建或压入一层符号表。
  • 声明阶段登记符号，引用阶段沿作用域链查找。
  • 它用于发现重复声明、未定义变量、类型不匹配，也为后续代码生成提供地址信息。

Q36: 编译器如何处理作用域和变量遮蔽？​

答案：

编译器通常维护嵌套作用域栈，查找变量时从当前作用域逐层向外搜索。内层同名声明会遮蔽外层符号，但不会修改外层绑定。

实现时要为不同声明分配唯一内部标识，并在离开作用域时弹出对应符号表。静态分析工具还可以对可疑遮蔽给出告警，但要允许合法的局部重命名。

Q37: 什么是 SSA？它为什么利于优化？​

答案：

SSA 是静态单赋值形式，每个变量在 IR 中只被赋值一次；控制流汇合处通过 phi 节点选择不同路径的值。

单赋值让“一个值从哪里来、被谁使用”非常清晰，常量传播、死代码删除和数据流分析更容易实现。代码生成前通常还要消除 phi，转换回寄存器或内存操作。

Q38: 死代码删除的判断依据是什么？​

答案：

如果一条指令的结果没有任何可观察用途，并且执行它也没有副作用，就可以删除。

判断时不能只看返回值是否使用，还要考虑 I/O、异常、共享状态、函数调用和 volatile 访问。工程上常从根节点反向标记有用指令，再删除未被标记的纯计算。

Q39: 常量折叠和常量传播有什么区别？​

答案：

常量折叠是在编译期直接计算常量表达式，例如把 2 * 3 变成 6；常量传播是把已知常量沿数据流替换到后续使用点。

二者通常配合迭代：传播产生新的常量表达式，折叠再简化它们。要注意语言的溢出、浮点和异常语义，不能改变运行结果。

Q40: 什么是控制流图？​

答案：

控制流图把连续执行的基本块作为节点，把跳转、分支和异常路径作为边。它是数据流分析和大量优化的基础。

编译器会在跳转目标、分支后和函数入口切分基本块，再建立前驱与后继关系。基于它可以计算可达性、支配关系、活跃变量和循环。

Q41: 支配关系在编译器中有什么用途？​

答案：

如果从入口到节点 B 的所有路径都必须经过节点 A，就说 A 支配 B。支配树可以判断某个定义是否在所有路径上先于使用。

它常用于构造 SSA、代码移动和循环分析。回答时可以强调：支配描述的是控制流上的“必经关系”，不是源码位置上的先后。

Q42: 编译器如何做错误恢复？​

答案：

好的解析器不会遇到第一个错误就完全退出，而会报告当前位置、期望 Token 和上下文，然后跳到可同步的位置继续解析。

常见做法是恐慌模式：跳过 Token，直到分号、右括号或下一条声明。恢复策略必须保证解析器持续前进，避免同一位置反复报错，同时尽量减少级联误报。

Q43: JIT 编译为什么需要分层优化？​

答案：

JIT 先用低成本基线编译快速启动，再根据运行时热点和类型反馈编译高频路径。这样在启动时间与峰值性能之间取得平衡。

激进优化依赖运行时假设；假设失效时要去优化并回退到通用代码。因此 JIT 还要维护热点计数、内联缓存和安全点。

Q44: 什么是去优化？​

答案：

去优化是 JIT 发现先前的优化假设不再成立时，把正在执行的优化代码恢复为较通用的执行状态。

例如某属性长期都是整数，优化器生成了专用代码，后来出现字符串就需要回退。频繁在优化与去优化之间震荡会损害性能，所以业务代码应尽量保持对象形状和类型稳定。

Q45: 编译器前端和后端如何划分？​

答案：

前端负责与源语言相关的解析、语义检查和生成 IR；后端负责与目标平台相关的优化、指令选择、寄存器分配和机器码生成。

IR 是二者之间的稳定边界，使多种源语言可以复用同一后端，也让一个前端支持多个目标平台。实际系统还可能有独立的中端优化层。

相关链接​