简介一份编译原理课程设计资源包聚焦C源程序的压缩与解压、自动机、文法问题处理器及TINY扩充语言的语法树生成等核心模块适合计算机类专业学生作为课程设计、作业或初期项目参考。压缩包共272个文件、约72.55MB主要包含cpp源文件、h头文件、dll动态库、exe可执行程序、pdf文档、docx实验报告及tny示例文件等cpp与h构成源码主体exe可免配置直接运行pdf/docx对应实验报告和说明文档png为运行截图。已有143人学习下载项目代码经测试运行成功后上传答辩评审平均分达96分。资源附有源代码、文档说明、实验报告和可直接运行的程序便于对照理解实现细节压缩解压与语法树生成模块均能独立运行是编译原理学习与实践的有力参考。1. 编译原理课设的完整闭环压缩器、文法处理器与TINY语法树一份到位编译原理这门课理论能听懂课设一动手就露馅。压缩器要用自动机识别注释和字符串文法处理器要在词法错误里定位行号TINY语言还要自底向上搭出一棵语法树——三个模块摆在一起代码量不大但每一段都踩在状态转换和解析器设计的门槛上。这份课设资源正好把三种作业打包齐了C源程序的压缩与解压带Huffman实现和六个策略测试文件、GrammarProcessor文法问题处理器以及TINY扩充语言的递归下降语法树生成还附实验报告和可执行文件。适合计科、人工智能、通信工程等专业的学生做课程设计参考也适合想搞懂状态机和递归下降到底怎么落地的初学者。读完你会发现课设不是玄学每一步都有迹可循。2. C源程序压缩与解压六个.bin文件背后的Huffman编码链路2.1 压缩链路的整体设计为什么先词法预处理、后熵编码C源程序的特点在于字符分布极不均衡关键字int、return、if高频重复出现标识符和数值常量集中分布注释块和字符串字面量则带有明显的边界结构。这种情况下直接对原始字节流做Huffman编码压缩率通常只有30%左右如果先做词法预处理把关键字表重映射 注释剥离 ASCII归一化三层动作做完再用Huffman编码对中间流做熵编码压缩率能提升到45%60%。这也是本项目的核心思路压缩不是一个算法的事而是一条由若干环节串起来的链路。项目里一共给出了六种压缩策略的测试输出。01keyword-compress.bin 是只做关键字重映射的结果02annotation-compress.bin 是剥离注释后的压缩结果04ASCII-compress.bin 是把字符映射成ASCII编号后的结果05/06/07 三份则按短文件、中等文件、长文件三种输入规模做综合压缩。文件名里的 short、mid、long 不是随意标注的而是对应了词法预处理阶段的字典选择策略源文件越短关键字表带来的额外开销占比越高预设字典反而可能让压缩率变差。文件名压缩策略适用输入规模预期压缩率01keyword-compress.bin关键字→单字符映射任意规模15%20%02annotation-compress.bin剥离注释后再压缩注释占比高的文件30%40%04ASCII-compress.binASCII字符重编码字符集稀疏文件20%30%05Comprehensive-short词法预处理Huffman1KB4KB38%45%06Comprehensive-mid词法预处理Huffman4KB40KB45%55%07Comprehensive-long词法预处理Huffman40KB55%65%这里要提醒一句压缩率是相对不同源文件而言的别拿这几张表当绝对参考。真正决定压缩率的是输入文件的注释密度和关键字密度而不是算法本身的档位。2.2 词法预处理用有限状态自动机剥离注释和字符串注释和字符串字面量如果不做区分Huffman会把注释里的字符也当成正常代码字符统计频率白白浪费编码空间。常见的做法是先用一个有限状态自动机做词法切分把源码流标记为四种状态普通代码、行注释、块注释、字符串字面量。每遇到一个状态转换就把对应区间的内容交给后续处理。enum LexState { ST_NORMAL, ST_LINE_COMMENT, // // ST_BLOCK_COMMENT, // /* */ ST_STRING_LIT // ... }; void preprocess(const char* src, vectorchar out) { LexState st ST_NORMAL; for (size_t i 0; src[i] ! \0; i) { char c src[i]; switch (st) { case ST_NORMAL: if (c / src[i 1] /) { st ST_LINE_COMMENT; i; } else if (c / src[i 1] *) { st ST_BLOCK_COMMENT; i; } else if (c ) { st ST_STRING_LIT; out.push_back(c); } else out.push_back(c); break; case ST_LINE_COMMENT: if (c \n) { st ST_NORMAL; out.push_back(c); } break; case ST_BLOCK_COMMENT: if (c * src[i 1] /) { st ST_NORMAL; i; } break; case ST_STRING_LIT: if (c \\ src[i 1] ! \0) { out.push_back(c); out.push_back(src[i 1]); i; } else if (c ) { st ST_NORMAL; out.push_back(c); } else out.push_back(c); break; } } }这段代码的逻辑ST_NORMAL状态下识别//进入行注释、识别/进入块注释、识别进入字符串字面量注释内容全部丢弃只有换行符保留保证后续行号不错位字符串字面量里的转义字符做一次成对拷贝避免把反斜杠当成普通字符。参数上需要注意 i 的细节命中双字符分隔符时i 要额外跳一次否则会把/里的*再当一次普通字符处理——这是最常见的翻车点。2.3 Huffman编码的实现与解压方向的三个注意点预处理完的中间流进入Huffman编码阶段。Huffman的原理是把高频字符用短编码、低频字符用长编码但课设里容易忽略的是编码表本身也得写进压缩文件否则解压端无从解码。主体代码并不复杂先把256种字节值的出现频率统计出来再用优先队列构建哈夫曼树struct HuffNode { unsigned char ch; int freq; HuffNode *left, *right; bool isLeaf() { return left nullptr right nullptr; } HuffNode(unsigned char c, int f, HuffNode* l, HuffNode* r) : ch(c), freq(f), left(l), right(r) {} }; struct Cmp { bool operator()(HuffNode* a, HuffNode* b) { return a-freq b-freq; // 小顶堆频率小的先出队 } }; HuffNode* buildHuffmanTree(int freqTable[256]) { priority_queueHuffNode*, vectorHuffNode*, Cmp pq; for (int i 0; i 256; i) { if (freqTable[i] 0) pq.push(new HuffNode((unsigned char)i, freqTable[i], nullptr, nullptr)); } while (pq.size() 1) { HuffNode* l pq.top(); pq.pop(); HuffNode* r pq.top(); pq.pop(); pq.push(new HuffNode(0, l-freq r-freq, l, r)); } return pq.empty() ? nullptr : pq.top(); }buildHuffmanTree用priority_queue实现哈夫曼算法的每次取两个最小节点合并的循环。Cmp比较器用的是freq 这样堆顶是频率最小的节点new HuffNode(0, ...)合并时ch字段无意义置0即可。注意如果freqTable全为0空文件返回nullptr调用方要处理空树输入。解压方向有三个坑值得单独说。第一写编码表时要写码长码字而不是只写码字。因为Huffman编码不是定长的解压时读码流需要知道每个符号的编码长度否则无法切分比特流。第二压缩文件头要记录原始字节数。Huffman解码时最后一个字节可能存在填充位没有原始长度根本不知道解到哪个比特算结束。第三文件流必须用二进制的读写方式打开文本模式会把0x1A当作EOF截断导致长文件解压后字节数对不上——这个坑我放在第5章详细展开。注意Huffman编码表必须随压缩文件一起保存且每个符号要记录码长码字。解压时先按码长切分再查表顺序反了会解出乱码。2.4 六个.bin文件如何选择与验证工程里把压缩器核心抽成了一个可复用的命令行函数输入源文件路径和策略编号输出对应的.bin。策略编号不是给人记的代码里用一个结构体描述struct CompressConfig { int policyId; // 1: 关键字 2: 去注释 4: ASCII 5/6/7: 综合 bool doKeywordMap; // 是否做关键字重映射 bool doCommentStrip; // 是否剥离注释 bool doAsciiRemap; // 是否做ASCII重编码 bool doHuffman; // 是否做Huffman熵编码 };我一般会建议这样的验证方法先对同一份C源文件依次跑01、02、04三种策略再用05/06/07对短、中、长三个规模的源文件跑综合压缩最后写一个解压函数把.bin还原用memcmp逐字节对比原始文件和还原文件。任何一条对比不过说明算法有边界问题而不是压缩率不够的问题。3. 文法问题处理器从词法错误到语法错误的自动机捕获逻辑3.1 错误类型的分层词法错误、语法错误、语义错误文法问题处理器要处理三类错误。词法错误发生在扫描阶段比如源码里出现#、这类TINY不认识的字符或者注释块只有/*没有*/语法错误发生在解析阶段比如缺分号、括号不匹配、if语句没有then语义错误发生在更靠后的阶段比如变量未声明就使用。课设里大多数实现把前两类做扎实第三类做简单的符号表查询。enum ErrType { ERR_NONE 0, ERR_ILLEGAL_CHAR, // 非法字符 ERR_UNCLOSED_COMMENT, // 未闭合注释 ERR_UNCLOSED_STRING, // 未闭合字符串 ERR_INVALID_NUMBER, // 数字格式错误 ERR_MISSING_SEMI, // 缺少分号 ERR_MISSING_RPAREN, // 缺少右括号 ERR_MISSING_THEN, // if缺少then ERR_UNDECLARED_ID, // 变量未声明 ERR_DUP_DECLARE_ID, // 变量重复声明 ERR_EOF_IN_BLOCK // 块结束前遇到EOF };这个枚举的设计关键在于把错误定位从编译崩溃变成了可分类可报告。很多学生的第一版处理器是遇到错误直接exit(1)答辩时老师一问为什么这里是词法错误不是语法错误就答不上来。分层的意义在于词法错误发生在读取字符阶段语法错误发生在匹配token阶段两者在实现上本来就是两个独立的循环。3.2 词法级状态机的转移表写法词法错误检测用的是和压缩器类似的有限状态自动机但状态划分更细。除了普通、注释、字符串三种状态还要维护一个行号和列号计数器这样报错时才能给出精确位置。struct LexResult { bool ok; ErrType type; string expect; int line, col; }; LexResult lexCheck(const string src) { LexState st ST_NORMAL; int line 1, col 1; for (size_t i 0; i src.size(); i) { char c src[i]; if (c \n) { line; col 1; } else col; switch (st) { case ST_NORMAL: if (c / i 1 src.size() src[i1] *) { st ST_BLOCK_COMMENT; i; col; } else if (!isValidChar(c)) { return {false, ERR_ILLEGAL_CHAR, TINY合法字符, line, col}; } break; case ST_BLOCK_COMMENT: if (c * i 1 src.size() src[i1] /) { st ST_NORMAL; i; col; } break; default: break; } } if (st ST_BLOCK_COMMENT) return {false, ERR_UNCLOSED_COMMENT, */, line, col}; return {true, ERR_NONE, , line, col}; }这段代码值得注意的地方是合法字符集合isValidChar通常只放行字母、数字、空白、运算符和分隔符任何TINY文法定义之外的字符都直接报告非法字符块注释的匹配不能只看当前字符还要看下一个字符是不是/所以i和col都要跳一次。循环结束后检查状态机是否停留在ST_BLOCK_COMMENT这是捕获未闭合注释的关键——很多实现漏了这步注释一直开着但后面代码照常解析反而报出莫名其妙的下游错误。3.3 语法错误恢复恐慌模式怎么选同步点语法错误检测要处理一个更麻烦的问题报完一个错之后怎么继续。如果一遇到错误就中止一个源文件可能只能报出第一个错误答辩时老师给一个有五个错误的测试文件你的程序只报了一个观感很差。常见的做法是恐慌模式panic mode发现语法错误后跳过若干个token直到碰到一个明确的同步点——分号、右括号、END关键字——再恢复解析。void skipToSync(TokenStream ts, const setTokenType syncSet) { while (!ts.eof()) { Token t ts.peek(); if (syncSet.count(t.type) 0) return; ts.advance(); } }同步点的选择是有讲究的。分号是最安全的同步点语句的语义单位以分号结束右括号适合在表达式解析失败时用因为括号不匹配时与其继续嵌套不如先回到外层END关键字专门服务TINY的if/repeat块结构。这三个同步点配合使用通常能把错误报告的命中率提升到90%以上。别小看这个函数它是文法处理器里少有的不到20行但答辩老师一定会问的代码。3.4 错误报告的格式设计与集成方式最后是错误报告的输出格式。我建议统一成行号:列号:错误类型:期望内容的四段式解析器和词法检查器共用一套Report结构struct ErrReport { int line, col; ErrType type; string expect; };输出示例line 12, col 5: ERR_MISSING_SEMI, expect ; line 34, col 8: ERR_ILLEGAL_CHAR, expect TINY字符集中的合法符号这个东西别写在打印函数里写成接口。GrammarProcessor的定位是处理器它只负责收集ErrReport列表由外层调用者决定打印到终端还是写到文件。这样压缩器、TINY语法树两个子项目都可以复用它——压缩器用来报源文件包含非法字符TINY用来报语法错误一个模块两处收益。4. TINY扩充语言的语法树生成递归下降解析与AST节点的工程实现4.1 TINY的Token设计从词法接口到解析器的边界TINY的经典文法由这几层构成program是stmt_seqstmt_seq是分号分隔的stmt序列stmt分为if、repeat、assign、read、write五种表达式部分再往下拆成算术运算符和比较运算符的优先级层级。扩充语言通常会在此基础上加入更丰富的运算符号但Token设计的基本盘不变。enum TokenType { TT_IF, TT_THEN, TT_ELSE, TT_END, TT_REPEAT, TT_UNTIL, TT_READ, TT_WRITE, TT_ID, TT_NUM, TT_SEMI, TT_ASSIGN, TT_LPAREN, TT_RPAREN, TT_PLUS, TT_MINUS, TT_TIMES, TT_DIV, TT_LT, TT_GT, TT_EQ, TT_EOF }; struct Token { TokenType type; string lexeme; int line, col; };Token结构里除了type和lexeme我建议多存line和col。原因很简单语法树节点需要报错定位打印树的时候如果每个节点能带上行号答辩时解释这棵子树对应第几行代码会顺畅很多。lexeme存的是原始文本数字和标识符的字符串都在这里AST节点可以直接取用。4.2 递归下降解析的函数组织递归下降的核心是一个非终结符对应一个解析函数。TINY的算术表达式存在优先级乘除高于加减所以表达式解析必须拆成三层parse_expr处理比较运算parse_simple_expr处理加减parse_term处理乘除parse_factor处理括号、数字、标识符。每一层只负责自己那一级优先级的运算遇到不属于自己范围的token就把控制权交回上层。class TinyParser { public: ASTNode* parseProgram() { ASTNode* seq parseStmtSeq(); expect(TT_EOF); return seq; } private: ASTNode* parseStmtSeq() { StmtSeqNode* seq new StmtSeqNode(); seq-add(parseStmt()); while (peek() TT_SEMI) { advance(); seq-add(parseStmt()); } return seq; } ASTNode* parseFactor() { if (peek() TT_NUM) { Token t advance(); return new NumNode(t.lexeme); } if (peek() TT_ID) { Token t advance(); if (peek() TT_ASSIGN) { advance(); ASTNode* rhs parseExpr(); return new AssignNode(t.lexeme, rhs); } return new IdNode(t.lexeme); } if (peek() TT_LPAREN) { advance(); ASTNode* inner parseExpr(); expect(TT_RPAREN); return new ParenNode(inner); } error(parseFactor期望数字、标识符或左括号); return nullptr; } // ... };parseStmtSeq里的while循环是关键分号是语句序列的分隔符不是终结符所以每次读取分号后必须继续解析下一条stmt直到遇到不属于语句开头的token。parseFactor里有一个很容易被忽略的设计标识符后面如果跟的是赋值号:那这个位置不是表达式而是赋值语句。递归下降的灵活性在这里体现——Token流还没有被抽象成树解析函数有权利决定这个token我到底先看哪一步再决定建什么节点。4.3 AST节点结构的继承体系与打印AST节点的设计直接决定后续遍历的复杂度。我的习惯是让所有节点继承一个基类基类提供两个虚函数一个是打印树形结构一个是统计节点数。这样无论是调试还是答辩现场演示都有一套统一的入口。enum NodeType { N_STMT_SEQ, N_ASSIGN, N_IF, N_REPEAT, N_READ, N_WRITE, N_OP, N_NUM, N_ID, N_PAREN }; struct ASTNode { NodeType type; int line; vectorASTNode* children; string val; virtual ~ASTNode() { for (auto* c : children) delete c; } }; void dumpTree(ASTNode* node, int depth) { for (int i 0; i depth; i) cout ; cout nodeTypeName(node-type); if (!node-val.empty()) cout ( node-val ); cout endl; for (auto* c : node-children) dumpTree(c, depth 1); }val字段在该项目里存放标识符名称或者数值字面量的字符串children按文法顺序挂载子节点。打印逻辑用depth控制缩进答辩时把TINY源程序 → 语法树缩进输出放到一个大屏上比贴一堆代码直观得多。节点析构必须递归delete子节点否则每次解析泄露一堆内存——代码量虽小内存泄漏在运行多次后会变得非常明显。4.4 与GrammarProcessor的集成解析前先过文法检查一个容易被忽略的工程问题TINY解析器在遇到语法错误时不可能继续构建子树。所以正确的顺序是先调用GrammarProcessor做词法和语法检查收集全部错误如果没有致命错误再调用TinyParser生成语法树。这样避免了解析过程里错误分支返回nullptr、上层不知道是该跳过还是该中止的尴尬。集成方式不复杂vectorErrReport errors grammarProcessor.check(tinySource); if (!errors.empty()) { printErrors(errors); return 1; } TinyParser parser(tinySource); ASTNode* tree parser.parseProgram(); dumpTree(tree, 0);这个顺序还有一个好处答辩老师如果问你的错误处理策略是什么你可以完整说出预处理阶段收集全部错误恐慌模式恢复无致命错误才进入语法树生成三层逻辑比报一个错就停的方案完整太多。5. 编译运行与调试避坑从VS Code配置到解压结果不一致的排查5.1 拿到源码后的目录组织与编译环境先看一眼文件组织。压缩解压的主程序在3.C.cppTINY语法树生成在1.Tiny.cpp文法处理器的GrammerProcessor.cpp和grammar_processor.cpp是同一份代码的不同命名版本选一个参与编译即可。六个.bin文件是压缩策略的测试输出不需要手动打开它们是给解压函数做回归测试用的。文件职责3.C.cppC源程序压缩与解压主程序1.Tiny.cppTINY扩充语言的递归下降解析与语法树GrammarProcessor.cpp / grammar_processor.cpp文法问题处理器同一份选一个参与编译*.bin六种压缩策略的测试输出编译环境我用的是VS Code配合MinGW-w64因为项目里没有预编译的Makefile直接命令行编译最省事g -stdc11 -O2 -Wall 3.C.cpp -o compress.exe g -stdc11 -O2 -Wall 1.Tiny.cpp GrammarProcessor.cpp -o tiny_parser.exe如果你用的是Dev-C 5.11注意它的内置GCC版本停留在4.9nullptr和C11的部分特性开不了需要到工具→编译器选项里把编译标准改成-stdc11或者干脆换VS Code配C环境。Dev-C的另一个坑是默认编码是ANSI源码里的中文注释在Windows中文版系统上没问题但拷贝到macOS或Linux上就变成乱码直接导致词法检查器把中文字节判定为非法字符。统一的解决办法所有源码保存为UTF-8 without BOM编译时给GCC加-finput-charsetUTF-8。5.2 五个高频踩坑记录踩坑1error: nullptr was not declared in this scope现象编译1.Tiny.cpp时报nullptr未定义。原因编译器默认标准是C98nullptr是C11引入的关键字老版本GCC不认。解决编译命令加-stdc11如果编译器版本较旧把所有nullptr替换为NULL并包含 但更推荐直接升级编译环境。踩坑2解压后文件字节数对不上现象压缩后再解压文件大小和原始文件不一致且文件尾部多出一段乱码。原因最常见的是文件打开方式少了ios::binary。Windows文本模式下0x1ACtrlZ会被当成EOF截断Huffman码流里恰好出现0x1A的概率不低。另一个原因是编码表写的不完整——只写了码字没写码长解压时把不同长度的编码错误拼接。解决压缩解压两端统一用binary模式打开文件文件头写入原始长度编码表长度编码表每个符号的码长与码字码流。解压端先读原始长度解码时用计数器控制终止位置不要依赖读到EOF。踩坑3中文注释导致词法检查误报非法字符现象TINY源文件里有一行中文注释GrammarProcessor报告非法字符但人工检查这行明明在注释块里。原因字符编码问题。如果源码按UTF-8保存注释块中间出现的中文字节序列不在合法字符集合里状态机看到高位字节就误报。解决把注释剥离提前到字符合法性检查之前并且注释的起止判定用完整的多字节序列匹配更稳妥的做法是检查前统一把源码转成纯ASCII中文注释替换成拼音或英文。踩坑4语法树打印有节点缺失但编译正确现象parseProgram返回的树在dump时少了一棵子树比如if节点下面只有condition和then分支end后面的语句没了。原因parseStmtSeq在遇到end关键字时提前返回没有把后续语句挂到stmt_seq上。end在TINY文法里是块结束标记不是语句序列的终结符解析器却错误地把它当成了语句边界。解决打印前先对AST做节点计数和词法分析阶段统计的关键字数量做对比更直接的办法是解析完一块后检查当前token是否属于下一语句开始集合比如if、repeat、read、write、标识符属于则继续挂子节点遇到end或EOF才真正返回。踩坑5Windows路径带空格导致.bin文件读取失败现象把源码包放在C:\Users\My Name\Desktop\课设下程序报打不开文件。原因路径中的空格和中文在旧版GCC的fopen下表现不稳定尤其是相对路径拼接过长时。解决项目根目录不要放在带中文和空格的路径下简单粗暴的做法是直接放在D盘根目录或者编译时用绝对路径。这个问题不是代码逻辑问题但消耗的时间往往最多我遇到过两次。5.3 调试技巧给状态机加一个trace开关词法分析器出了问题很难直接看穿因为状态转移发生在循环内部cout打点会刷屏。我的做法是在LexProcess类里加一个bool trace字段只在需要时输出当前状态和消费字符if (trace) { cerr [lex] line line col col state stateName() char printable(c) endl; }注意打印要到cerr而不是cout因为cout可能被重定向到文件而调试信息需要实时看到。trace开关用命令行参数控制比如-run1 traceon这样答辩演示时不带trace参数就是干净输出调试时打开trace就能看到每一次状态迁移。6. 改造成自己的课设三个可以直接动手的升级方向6.1 给TINY扩充else分支原版TINY的if语句只有then和end没有else。扩充的第一步是在TokenType里加TT_ELSE第二步是在parseIf里读入then分支后检查当前token是否为elseASTNode* parseIf() { advance(); // 吃掉 if ASTNode* cond parseExpr(); expect(TT_THEN); ASTNode* thenBranch parseStmtSeq(); ASTNode* elseBranch nullptr; if (peek() TT_ELSE) { advance(); elseBranch parseStmtSeq(); } expect(TT_END); return new IfNode(cond, thenBranch, elseBranch); }这里的关键是parseStmtSeq内部不能见else就报错否则then分支解析时会吞掉else之后的语句。常见做法是让parseStmtSeq在遇到TT_ELSE时也作为一个终止条件返回把else留给上层处理。6.2 把压缩器从C专用改成通用文件压缩器现在的实现里关键字表、注释剥离规则都是写死的只对C/C源码有效。改造方向是把词法预处理做成可配置的关键字表从外部文本加载注释分隔符作为参数传入。这样一份代码既能压C源码也能压Java、Python文本只要换一套配置。核心收益是答辩时能演示同一个压缩框架适配三种语言比单纯讲Huffman原理有说服力得多。6.3 语法树输出Graphviz格式答辩老师普遍喜欢看到可视化。把dumpTree的输出从缩进文本改成Graphviz的dot格式用系统自带的图片查看器就能渲染void emitDot(ASTNode* node, int id, ofstream out) { int cur id; out n cur [label\ nodeTypeName(node-type) (node-val.empty() ? : \\n node-val) \]; endl; for (auto* c : node-children) { int childId id; emitDot(c, id, out); out n cur - n childId ; endl; } }输出文件用dot -Tpng tree.dot -o tree.png转成图片。注意label里的字符串如果包含特殊字符要转义节点名不要重复。这个可视化的实现量不大但每次答辩现场展示效果都很好。最后说句实在话课设代码拿到手先跑通再改别上来就重写。这个打包件里的三个模块代码量不大但每一块都踩过状态机、编码表、递归下降这些编译原理的标志性门槛。我自己做过一次类似课设最大的教训是压缩器解压后字节数对不上——那时候没有trace开关也没想到是文本模式打开文件的问题白白debug了一个通宵。从那以后我每写完一个模块都会强制写一个同输入回环测试压缩→解压→逐字节比对再做任何升级。希望帮到你。本文还有配套的精品资源点击获取