简介：这份资源是编译原理课程实验三的语义分析实现包，面向正在学习编译原理、需要动手完成编译器前端实验的高校学生与自学者。它聚焦词法分析与语法分析之后的语义检查环节，帮助理解类型检查、作用域解析、常量折叠等核心概念在Java中的落地方式。压缩包共101个文件，约88KB，以35个java源码为主体，辅以14个xml配置、若干class字节码与prefs、lock等IDE工程文件，另有zip、segments_1、cfs、db等索引与缓存数据，整体是一套可直接导入运行的Eclipse或IDEA工程。资源已有1781人学习下载，说明其在同类实验资料中具备一定参考价值。读者可从中获得词法分析器、Token与Word类、语法树构建到语义分析器的完整代码骨架，并借助Main入口串联各阶段，对照调试类型不匹配、变量未声明、作用域冲突等典型问题，从而加深对编译器工作流程与Java类型系统的理解，为后续代码生成与静态分析工具开发打下基础。
1. 语义分析实验到底在做什么：从语法树到符号表的这一步
很多人做编译原理实验，语法分析跑通、AST 打印出来那一刻觉得稳了，结果一进语义分析就翻车——变量未声明不报错、类型不匹配照样过、作用域嵌套直接乱套。实验三的核心任务，就是把语法分析产出的抽象语法树拿过来，做一遍带符号表和作用域链的遍历，把「语法上合法但语义上说不通」的代码揪出来。标题里的 sectionnef 是这类实验里常见的语义分析入口或测试用例标识，通常对应一段需要做符号表填充、类型检查、作用域校验的源码片段。这一章先把语义分析在整条编译流水线里的位置、它和语法分析的本质区别、以及一个能跑通的实验三最小闭环讲清楚，适合正在被实验报告卡住、或者想自己从零补一遍语义分析实现的人。
语义分析不是「再解析一遍语法」。语法分析回答的是「这串 token 能不能构成合法句子」，语义分析回答的是「这个合法句子在程序里讲不讲得通」。举个最直接的例子：int a; a = "hello";语法上完全合法，声明语句、赋值语句都符合文法，但语义上类型不匹配。再比如{ int x; } x = 1;，语法没问题，但 x 出了作用域就不该可见。语义分析要做的，就是维护一张符号表记录每个标识符的类型、种类、作用域层级，在遍历 AST 的过程中不断查表、填表、比对类型，发现不一致就报错。
实验三通常要求你实现三件事：符号表的建立与管理、类型检查、作用域处理。符号表可以用哈希表或有序表实现，关键是支持插入、查找、删除（或作用域退出时的批量清理）。类型检查要覆盖基本类型（int、float、char、bool）之间的赋值兼容、运算类型推导、函数调用参数匹配。作用域处理要区分全局作用域、函数作用域、块作用域，进入块时压栈、退出块时弹栈。这三件事做扎实，实验三基本就稳了。
sectionnef 在这个语境下，一般是你实验里某个测试用例的名字或者语义分析模块的入口函数标识。不同学校的实验框架不一样，有的给的是 Java 的 AST 类库，有的给的是 C++ 的手写递归下降 parser 输出，但语义分析的核心逻辑是通的：遍历、查表、比对、报错。下面几章我会按「先建符号表 → 再做类型检查 → 再处理作用域 → 最后排错」的顺序，把每一步的实现细节和踩坑点讲透。
2. 符号表怎么建才不返工：数据结构选型与插入查找实现
符号表是语义分析的命根子。建得好，后面类型检查、作用域处理都是顺水推舟；建得烂，写到一半发现查不到外层变量、或者同名变量覆盖了不该覆盖的，就得推倒重来。这一章先把符号表的数据结构选型和核心操作讲清楚，再给一份能直接抄的 Java 实现。
2.1 为什么用「栈式作用域链 + 哈希表」而不是单一全局表
最常见的翻车做法是：全局开一个HashMap<String, Symbol>，遇到变量声明就 put，遇到变量引用就 get。单层作用域下没问题，一旦出现嵌套块就完蛋。比如：
int x = 1; { int x = 2; print(x); // 应该输出 2 } print(x); // 应该输出 1用单一全局表，第二个int x = 2直接把外层的 x 覆盖了，退出块之后外层 x 也回不来。正确做法是每个作用域一张表，作用域嵌套形成栈式结构。进入新作用域时压入一张新表，退出时弹出。查找变量时从栈顶往下逐层找，找到第一个匹配就返回。这样内层同名变量自然遮蔽外层，退出后外层变量自动恢复可见。
数据结构上，我一般用ArrayList<HashMap<String, Symbol>>表示作用域栈，栈顶是当前作用域。每个 Symbol 至少存：名字、类型、种类（变量/函数/参数）、声明行号、是否已初始化。种类字段很多人省掉，后面做函数调用检查时又得补，不如一开始就加上。
2.2 符号表插入与查找的 Java 实现
下面这份代码可以直接放进你的实验项目里，核心是enterScope、exitScope、insert、lookup四个方法：
import java.util.*; class Symbol { String name; String type; // "int", "float", "char", "bool", "function" String kind; // "variable", "function", "parameter" int line; boolean initialized; Symbol(String name, String type, String kind, int line) { this.name = name; this.type = type; this.kind = kind; this.line = line; this.initialized = false; } } public class SymbolTable { // 作用域栈，栈顶是当前作用域 private Deque<Map<String, Symbol>> scopeStack = new ArrayDeque<>(); public SymbolTable() { enterScope(); // 全局作用域 } // 进入新作用域：压入一张空表 public void enterScope() { scopeStack.push(new HashMap<>()); } // 退出作用域：弹出栈顶表 public void exitScope() { if (scopeStack.size() <= 1) { throw new RuntimeException("不能退出全局作用域"); } scopeStack.pop(); } // 插入符号：只查当前作用域是否重复 public boolean insert(Symbol sym) { Map<String, Symbol> current = scopeStack.peek(); if (current.containsKey(sym.name)) { return false; // 当前作用域已有同名符号 } current.put(sym.name, sym); return true; } // 查找符号：从栈顶往下逐层找 public Symbol lookup(String name) { for (Map<String, Symbol> scope : scopeStack) { Symbol s = scope.get(name); if (s != null) return s; } return null; // 未声明 } // 只查当前作用域，用于重复声明检查 public Symbol lookupCurrent(String name) { return scopeStack.peek().get(name); } }逻辑说明：scopeStack用ArrayDeque当栈使，push压栈、pop弹栈、迭代时从栈顶开始。insert只检查当前作用域是否重复，允许内层遮蔽外层——这是 C、Java 等语言的正确行为。lookup从栈顶往下遍历，保证内层优先。lookupCurrent单独暴露出来，是因为有些检查（比如同一作用域重复声明）只需要看当前层。
参数说明：Symbol的type字段建议用字符串而不是枚举，实验阶段改起来方便，后面做类型兼容判断时写个isCompatible(String t1, String t2)方法就行。line字段一定要存，报错时能直接定位到源码行，实验报告里也好写。initialized字段用于「变量未初始化就使用」的检查，虽然很多实验不要求，但加上不亏。
提示：如果你的实验框架要求符号表支持删除单个符号（比如函数参数在函数体结束后失效），不要真的去删，用作用域弹栈批量清理更安全，也不会漏。
2.3 插入时机与遍历顺序的配合
符号表建好了，什么时候插、什么时候查，取决于你 AST 的遍历顺序。常见做法是：遇到变量声明节点，先查当前作用域是否重复，不重复就插入；遇到标识符引用节点，调lookup查，查不到就报「未声明」。遇到块语句节点，进入时enterScope，退出时exitScope。遇到函数定义节点，先把函数名和返回类型插入外层作用域，再enterScope处理参数和函数体。
这里有个容易忽略的点：函数名应该在处理函数体之前就插入外层作用域，否则递归调用自己时会报「未声明」。我见过不少人在这里翻车，递归函数一调就报错，查半天才发现是插入顺序反了。
遍历顺序建议用后序遍历做类型检查（先处理子节点再处理父节点），但符号表的插入要用前序（先声明再使用）。实际实现时不用严格区分，在遍历到声明节点时立即插入、遍历到引用节点时立即查找即可，AST 的递归结构天然保证了声明在引用之前被访问——前提是你的遍历是从上到下、从左到右的。
3. 类型检查怎么做才不漏：从基本类型兼容到函数调用匹配
符号表建好之后，语义分析的第二大块就是类型检查。这一章把类型检查拆成三个层次：基本类型兼容判断、表达式类型推导、函数调用参数匹配。每一层都给可执行的判断逻辑和常见错误案例。
3.1 基本类型兼容规则与实现
类型兼容判断是类型检查的地基。不同语言的兼容规则不一样，实验里通常简化成：同类型兼容、int 可以隐式转 float、char 可以转 int、bool 不跟其他类型混。下面是一个典型的兼容判断实现：
public class TypeChecker { // 判断 from 类型能否隐式转换为 to 类型 public static boolean isCompatible(String to, String from) { if (to.equals(from)) return true; // int -> float 允许 if (to.equals("float") && from.equals("int")) return true; // char -> int 允许 if (to.equals("int") && from.equals("char")) return true; // 其他一律不兼容 return false; } // 二元运算结果类型推导 public static String binaryResultType(String left, String right, String op) { // 算术运算 if (op.equals("+") || op.equals("-") || op.equals("*") || op.equals("/")) { if (left.equals("float") || right.equals("float")) return "float"; if (left.equals("int") && right.equals("int")) return "int"; throw new RuntimeException("算术运算类型不匹配: " + left + " " + op + " " + right); } // 比较运算返回 bool if (op.equals("<") || op.equals(">") || op.equals("==") || op.equals("!=")) { if (!isCompatible(left, right) && !isCompatible(right, left)) { throw new RuntimeException("比较运算类型不匹配: " + left + " " + op + " " + right); } return "bool"; } throw new RuntimeException("未知运算符: " + op); } }逻辑说明：isCompatible(to, from)的参数顺序很重要，第一个是目标类型，第二个是源类型。int -> float允许但float -> int不允许，写反了就会放过不该放过的赋值。binaryResultType处理二元运算的结果类型，算术运算里只要有一个 float 结果就是 float，比较运算统一返回 bool。
参数说明：运算符集合按你实验文法里实际有的来，不要多写。如果实验支持%取模，记得%只对 int 有效，float 参与要报错。字符串类型如果实验里有，单独处理，不要混进数值兼容规则。
3.2 表达式类型推导的递归实现
表达式类型推导要跟着 AST 递归走。每个表达式节点返回自己的类型，父节点根据子节点类型和运算符算出自己的类型。核心代码如下：
// 假设 AST 节点类有 getType() 和 getChildren() public String checkExpr(ASTNode node) { switch (node.getKind()) { case "INT_LITERAL": return "int"; case "FLOAT_LITERAL": return "float"; case "CHAR_LITERAL": return "char"; case "BOOL_LITERAL": return "bool"; case "IDENTIFIER": { Symbol s = symbolTable.lookup(node.getValue()); if (s == null) { error(node.getLine(), "未声明的标识符: " + node.getValue()); return "error"; } if (!s.initialized && s.kind.equals("variable")) { error(node.getLine(), "变量未初始化就使用: " + node.getValue()); } return s.type; } case "BINARY_OP": { String lt = checkExpr(node.getLeft()); String rt = checkExpr(node.getRight()); return TypeChecker.binaryResultType(lt, rt, node.getOp()); } case "ASSIGN": { String lt = checkExpr(node.getLeft()); String rt = checkExpr(node.getRight()); if (!TypeChecker.isCompatible(lt, rt)) { error(node.getLine(), "赋值类型不匹配: " + lt + " = " + rt); } // 标记左值为已初始化 if (node.getLeft().getKind().equals("IDENTIFIER")) { Symbol s = symbolTable.lookup(node.getLeft().getValue()); if (s != null) s.initialized = true; } return lt; } default: return "error"; } }逻辑说明：每个 case 对应一种表达式节点。字面量直接返回类型。标识符查符号表，查不到报错，查到但未初始化也报错（如果实验要求）。二元运算递归求左右类型再推导结果。赋值语句检查右值能否赋给左值，同时把左值标记为已初始化。
参数说明：error方法建议收集错误而不是遇到第一个就抛异常，这样一次编译能报出所有语义错误，实验报告里也好看。initialized标记只在赋值语句里设置，声明时带初始化的（如int x = 1;）要在声明处理里就设好。
3.3 函数调用参数匹配的检查点
函数调用是类型检查里最容易漏的地方。要检查三件事：函数是否已声明、参数个数是否匹配、每个参数类型是否兼容。实现思路是：遇到函数调用节点，先lookup函数名，拿到函数的参数类型列表，再逐个比对实参类型。
case "FUNCTION_CALL": { Symbol func = symbolTable.lookup(node.getFuncName()); if (func == null || !func.kind.equals("function")) { error(node.getLine(), "未声明的函数: " + node.getFuncName()); return "error"; } List<String> paramTypes = func.getParamTypes(); // 函数符号里存参数类型列表 List<ASTNode> args = node.getArgs(); if (args.size() != paramTypes.size()) { error(node.getLine(), "参数个数不匹配: 期望 " + paramTypes.size() + " 个，实际 " + args.size() + " 个"); return func.type; } for (int i = 0; i < args.size(); i++) { String argType = checkExpr(args.get(i)); if (!TypeChecker.isCompatible(paramTypes.get(i), argType)) { error(node.getLine(), "第 " + (i + 1) + " 个参数类型不匹配: 期望 " + paramTypes.get(i) + "，实际 " + argType); } } return func.type; }逻辑说明：函数符号里需要额外存一个paramTypes列表，在函数声明处理时填充。参数个数检查要在类型检查之前，个数不对直接返回，不用再逐个比类型。类型比对用isCompatible(形参类型, 实参类型)，顺序不能反。
参数说明：如果实验支持默认参数或可变参数，这里要额外处理，但大多数编译原理实验不要求，别给自己加戏。返回值类型直接用函数符号的type字段。
注意：函数调用检查里最容易翻车的是「函数名和变量名同名」的情况。如果你的符号表 lookup 返回了变量符号而不是函数符号，后面取 paramTypes 会直接空指针。所以 lookup 之后一定要判断 kind，不是 function 就报错。
4. 作用域处理与遍历顺序：块、函数、循环的边界怎么划
作用域处理是语义分析里最考验细节的部分。块作用域、函数作用域、循环作用域各有各的边界规则，遍历时 enterScope 和 exitScope 的配对一旦出错，符号表就会错乱。这一章把常见作用域场景的处理方式和遍历顺序讲清楚。
4.1 块作用域与函数作用域的 enter/exit 配对
块语句{ ... }进入时 enterScope，退出时 exitScope，这个最直观。函数定义稍微复杂：函数名和返回类型插入外层作用域，然后 enterScope 处理参数和函数体，函数体处理完 exitScope。参数作为变量插入函数作用域，这样函数体内能查到参数。
// 处理块语句 case "BLOCK": { symbolTable.enterScope(); for (ASTNode stmt : node.getStatements()) { checkStmt(stmt); } symbolTable.exitScope(); break; } // 处理函数定义 case "FUNCTION_DEF": { // 函数名插入外层 Symbol funcSym = new Symbol(node.getName(), node.getReturnType(), "function", node.getLine()); funcSym.setParamTypes(node.getParamTypes()); if (!symbolTable.insert(funcSym)) { error(node.getLine(), "函数重复定义: " + node.getName()); } // 进入函数作用域 symbolTable.enterScope(); // 参数插入函数作用域 for (Param p : node.getParams()) { Symbol paramSym = new Symbol(p.getName(), p.getType(), "parameter", p.getLine()); paramSym.initialized = true; // 参数默认已初始化 if (!symbolTable.insert(paramSym)) { error(p.getLine(), "参数重复: " + p.getName()); } } // 处理函数体 checkStmt(node.getBody()); symbolTable.exitScope(); break; }逻辑说明：块语句的 enter/exit 严格配对，中间处理所有子语句。函数定义先插函数名再进作用域，参数插入函数作用域并标记已初始化。函数体处理完必须 exitScope，否则后续代码会看到函数内部的局部变量。
参数说明：paramSym.initialized = true这行别漏，参数在函数体内天然可用，不标记的话会误报「未初始化」。函数重复定义检查用insert的返回值，返回 false 说明当前作用域已有同名符号。
4.2 循环与条件语句里的作用域陷阱
循环和条件语句的作用域处理有个经典陷阱：循环变量在循环体结束后是否可见。C 语言里for (int i = 0; ...)的 i 只在循环内可见，但很多实验文法简化处理，把 i 放在外层作用域。这个要看你实验的具体要求，不能想当然。
// for 循环：循环变量在循环作用域内 case "FOR_STMT": { symbolTable.enterScope(); // 初始化语句 if (node.getInit() != null) checkStmt(node.getInit()); // 条件 if (node.getCond() != null) checkExpr(node.getCond()); // 更新 if (node.getUpdate() != null) checkExpr(node.getUpdate()); // 循环体 checkStmt(node.getBody()); symbolTable.exitScope(); break; }逻辑说明：for 循环整体包一个作用域，初始化、条件、更新、循环体都在这个作用域内。这样循环变量 i 在循环外不可见，符合 C/Java 语义。如果实验要求 i 在外层可见（有些简化文法这样），就把 enterScope 去掉，但要在实验报告里说明。
参数说明：while 循环不需要额外作用域，循环体如果是块语句，块自己会 enterScope。if 语句同理，条件表达式在外层作用域检查，分支体如果是块语句自己管作用域。
4.3 遍历顺序对符号表状态的影响
遍历顺序决定了符号表在某一时刻的状态。前序遍历（先处理父节点再处理子节点）适合声明收集，后序遍历（先处理子节点再处理父节点）适合类型检查。实际实现时不用严格区分，但要注意：声明节点必须在引用节点之前被访问。
一个常见的错误是：先遍历整个 AST 收集所有声明，再做类型检查。这样做的问题是，内层作用域的声明会被提前收集到外层，作用域信息丢失。正确做法是一边遍历一边处理，遇到声明就插入当前作用域，遇到引用就查找，作用域的 enter/exit 跟着 AST 结构走。
提示：如果你的实验要求先输出符号表再输出错误信息，可以在遍历过程中把符号表快照存下来，遍历结束后统一打印。不要在遍历中途打印，输出顺序会乱。
4.4 作用域退出时的清理策略
作用域退出时，栈顶的符号表直接弹出即可，不需要逐个删除符号。这是栈式作用域链的最大优势：退出即清理，O(1) 复杂度。但要注意，如果有跨作用域的引用（比如闭包），弹出后符号就查不到了。编译原理实验一般不涉及闭包，不用考虑。
如果实验要求支持「变量在作用域外被引用时报错」，弹出后 lookup 自然查不到，报「未声明」即可。如果要求报「超出作用域」，那需要在符号被弹出前记录它的作用域层级，查找失败时判断是否曾经存在过。这个需求少见，遇到了再处理。
5. 语义分析避坑清单：5 个让实验反复返工的典型问题
这一章集中讲踩坑。语义分析的 bug 往往不是逻辑不会写，而是细节没考虑到，导致实验反复返工。下面 5 条是我自己和身边人真实翻车过的记录，每条按「现象 → 原因 → 解决」写。
5.1 递归函数报「未声明」
现象：函数体内调用自己，语义分析报「未声明的函数」。
原因：函数名插入外层作用域的时机晚于函数体处理。先 enterScope 处理函数体，再插入函数名，导致函数体里 lookup 自己时查不到。
解决：调整顺序，先把函数名和返回类型插入外层作用域，再 enterScope 处理参数和函数体。这样函数体内 lookup 自己时能查到。
5.2 内层变量遮蔽外层后，退出块外层变量丢失
现象：嵌套块里声明同名变量，退出内层块后外层变量查不到。
原因：用了单一全局符号表，内层声明直接覆盖外层，退出时没有恢复机制。
解决：改用栈式作用域链，每个作用域一张表，进入压栈、退出弹栈。查找时从栈顶往下找，内层优先，退出后外层自然恢复。
5.3 赋值语句左值类型检查顺序错误
现象：float f; int i; f = i;报类型不匹配。
原因：isCompatible(to, from)参数写反了，写成了isCompatible(from, to)，导致float = int被判断为不兼容。
解决：统一约定isCompatible(目标类型, 源类型)，赋值检查时用isCompatible(左值类型, 右值类型)。写完后用int = float和float = int两个用例验证，前者应报错，后者应通过。
5.4 函数调用参数个数不匹配时数组越界
现象：函数调用参数个数少于形参个数时，程序抛数组越界异常。
原因：参数类型检查循环用了paramTypes.size()作为上界，但实参个数更少，访问args.get(i)时越界。
解决：先检查个数是否相等，不相等直接报错返回，不要进入逐个比对的循环。个数检查放在类型检查之前。
5.5 错误信息只报第一个就退出
现象：源码里有多个语义错误，但只报了第一个，后面的错误看不到。
原因：遇到错误就抛异常或 return，没有继续遍历。
解决：用错误列表收集所有错误，遇到错误时记录并继续遍历，最后统一输出。这样一次编译能报出所有问题，实验报告里也显得完整。注意有些错误会导致后续检查无法进行（比如符号表查不到），这种情况下可以跳过当前子树，但不要终止整个遍历。
注意：避坑清单里的每一条都建议在实验里写一个对应的测试用例，跑通之后再提交。语义分析的 bug 往往在边界用例上才暴露，正常代码反而看不出问题。
6. 用 sectionnef 做回归验证：一套可复用的语义分析测试方法
实验三做完，怎么验证自己的语义分析是对的？靠手工跑几个用例不够，边界情况很容易漏。这一章给一套可复用的测试方法，用 sectionnef 这类测试用例做回归验证，确保每次改代码不会引入新问题。
6.1 测试用例的分类设计
语义分析的测试用例分四类：正常用例、类型错误用例、作用域错误用例、声明错误用例。每类至少准备 3 个，覆盖边界情况。
| 类别 | 用例示例 | 期望结果 |
|---|---|---|
| 正常 | int a; a = 1; int b; b = a + 2; | 无错误 |
| 类型错误 | int a; a = "hello"; | 赋值类型不匹配 |
| 作用域错误 | { int x; } x = 1; | 未声明的标识符 |
| 声明错误 | int a; int a; | 重复定义 |
| 函数错误 | int f(int x) { return x; } f(1, 2); | 参数个数不匹配 |
| 递归 | int fact(int n) { if (n <= 1) return 1; return n * fact(n - 1); } | 无错误 |
sectionnef 如果是你实验里的测试用例标识，把它对应的源码片段跑一遍，看输出是否符合预期。如果 sectionnef 是语义分析入口，确保它接收 AST 后能正确输出错误列表。
6.2 自动化回归脚本
手工跑用例太慢，写个脚本批量跑。假设你的语义分析器有一个analyze(String source)方法返回错误列表，可以这样写：
public class SemanticTestRunner { public static void main(String[] args) { Map<String, String> cases = new LinkedHashMap<>(); cases.put("int a; a = 1;", ""); // 期望无错误 cases.put("int a; a = \"hello\";", "赋值类型不匹配"); // 期望报错 cases.put("{ int x; } x = 1;", "未声明的标识符"); // 期望报错 cases.put("int a; int a;", "重复定义"); // 期望报错 int passed = 0; for (Map.Entry<String, String> entry : cases.entrySet()) { List<String> errors = SemanticAnalyzer.analyze(entry.getKey()); String expected = entry.getValue(); boolean ok; if (expected.isEmpty()) { ok = errors.isEmpty(); } else { ok = errors.stream().anyMatch(e -> e.contains(expected)); } System.out.println((ok ? "PASS" : "FAIL") + " | " + entry.getKey()); if (!ok) { System.out.println(" 期望: " + (expected.isEmpty() ? "无错误" : expected)); System.out.println(" 实际: " + errors); } else { passed++; } } System.out.println("通过 " + passed + "/" + cases.size()); } }逻辑说明：用LinkedHashMap保持用例顺序，key 是源码，value 是期望的错误关键字（空字符串表示期望无错误）。analyze返回错误列表，逐个比对。期望无错误时检查列表为空，期望有错误时检查列表中是否有包含关键字的项。
参数说明：错误关键字用contains匹配而不是equals，因为实际错误信息可能带行号等额外内容。如果你的错误信息格式固定，可以改成更精确的匹配。用例集合按你的实验文法调整，确保每个语法特性都有覆盖。
6.3 我自己的验证习惯
我做完语义分析后，习惯先跑一遍正常用例确认不误报，再跑错误用例确认不漏报，最后跑一遍递归和嵌套作用域的复杂用例确认边界没问题。每次改完代码，不管改多小，都把这套用例重跑一遍。血泪经验是：语义分析的 bug 往往在你改了一个看似无关的地方之后冒出来，回归测试是唯一的后悔药。
sectionnef 这类测试用例的价值在于，它通常覆盖了实验要求的所有语义检查点，跑通它基本就覆盖了评分点。但别只跑它一个，自己补几个边界用例，比如空块、多层嵌套、函数嵌套调用，这些才是真正拉开差距的地方。
希望帮到你。
本文还有配套的精品资源，点击获取
