从词法分析到三地址码：小型编译器的链路与避坑-北京尧图网络

简介面向计算机专业编译原理课程设计与实验环节的配套资料包适合正在完成词法分析、语法分析及小型编译器实现的学生参考。内容围绕词法分析器、LL(1)文法分析简单语句如 ii*i、LR(0)与SLR(1)语法分析、四元式生成和汇编代码生成等模块展开并附课程设计报告可帮助读者把课堂中的文法理论、分析表构造与程序实现对应起来。资料中还给出部分LL(1)文法与一个SLR(1)文法便于对照梳理FIRST/FOLLOW集、项目集规范族及分析表构造。全包共14个文件以C/C源码、头文件、说明文本和文档报告为主rar压缩后约557KB目录紧凑便于按实验模块查阅与复现。已有2350人学习下载对于需要理解词法分析流程、查看四元式到汇编代码生成脉络的读者这份资料能提供较完整的课程设计参照。1. 词法分析为什么不是「切字符串」一条从字符到 token 的翻译链很多人对编译原理课程设计的第一印象是写一堆 if-else 把字符流切成 token再照着文法抄几个递归函数。真正动手才会发现卡住你的从来不是「怎么切」而是切错一个字符之后整条流水线怎么把错误定位回源码的第几行第几列。词法分析、语法分析、小型编译器这条链路本质上在做同一件事把没有结构的字符流逐层翻译成有结构、可验证、可复现的中间表示而每一层都必须为下一层保留「出错时能回溯到哪里」的信息。搞懂这条链路的底层机制课程设计才不会退化成对着实验报告凑输出也才能在答辩被追问「为什么这里要回退一个字符」时讲出个所以然。2. 词法分析的底层机制正则、DFA 与最长匹配的边界词法分析器的理论模型非常干净正则表达式定义词法规则Thompson 构造把正则变成 NFA子集构造把 NFA 变成 DFADFA 最小化去掉冗余状态最后那张转移表就是扫描器。这条路径教科书里写得明明白白但课程设计里真的照着生成一遍往往会得到一个既难调试、又对不上实验报告输出格式的东西。原因不在于理论有错而在于理论模型省略了三个工程约束最长匹配要求的状态停留、错误恢复要求的字符回退、以及位置信息行列号的维护。2.1 从正则到自动机子集构造到底在合并什么NFA 的关键特征是「一个状态读入一个字符后可以走到多个状态」这让它天然适合表达a|b、a*这类选择与重复但也让它无法用一张二维表直接驱动。子集构造做的事情是把「当前可能处于的状态集合」整体当成 DFA 的一个状态于是 ε 闭包把不确定性收进了状态本身。理解这一步的分水岭在于DFA 的状态不是源码里的某个位置而是「到目前为止我可能匹配到哪几条规则的第几个字符」。这个视角能解释很多实际现象。比如关键字和标识符为什么通常共用一条自动机路径if、int和if_count在扫描到第三个字符之前是完全无法区分的DFA 只能先把整个词素吃下来再靠一张关键字表做二次判定。真把关键字做成独立分支反而会让状态数膨胀还容易在intx这种输入上匹配错。常见的实现思路是用哈希表存关键字查表 O(1)比把几十个关键字铺成一棵前缀树更省事调试时也更容易看清楚「到底命中了哪条规则」。子集构造还有一个副作用值得注意状态数可能指数级膨胀。课程设计里的词法规则一般只有几十条不会触发这个问题但如果把注释、字符串字面量、浮点数的各种边界写法都塞进正则生成出来的表驱动 DFA 会变得难以人工检查。所以我一般会这么理解自动机是给你用来验证规则完备性的不是给你用来直接跑的。规则写成正则、心里过一遍 NFA、确认没有「接受态还能继续吃字符」的歧义这比真的跑一遍生成器更有价值。2.2 最长匹配与回退多读一个字符的代价最长匹配maximal munch是词法分析里最容易被低估的一条约定当多个规则都能匹配当前前缀时选最长的那个长度相同时选规则里排在前面的那个。和的区分就靠它——扫描到时你不能立刻返回必须再读一个字符看看是不是如果不是就得把这个字符「还回去」。回退这个动作在代码里只有一行但它牵扯出两个隐蔽的坑。第一是缓冲区如果用fgetc直接读文件回退要靠ungetc而ungetc的标准只保证回退一个字符如果用手写缓冲区回退就是把读指针减一代价几乎为零这也是lex这类工具采用双缓冲加哨兵字符的原因。第二是位置信息你为了判断多读了一个字符列号已经加一了回退时如果不把列号减回去后面所有 token 的列号都会偏一位报错信息就全歪了。行号更麻烦因为多读的那个字符理论上可能是换行符跨行回退必须由调用方保证不发生。浮点数和注释是这条规则的压力测试点。1.后面跟的是数字还是运算符决定了它是1.0还是「整数 1 加一个点」/后面跟*是块注释开始否则是除法。这些判断都依赖「先多看一位再决定收不收」。血泪经验是把所有需要前瞻的规则集中列一张表写清楚每条规则最多需要看几位然后统一用同一个peek(n)接口去取不要让每个函数自己fgetc再自己ungetc否则回退次数一多行列号必然对不上。2.3 手写扫描器为什么还要维护状态机课程设计里最常见的写法是一个大switch套while看起来跟「状态机」没关系其实它就是状态机的手工展开switch的分支是状态while的循环是转移循环条件里的字符判断是转移条件。区别只在于状态没有被显式编号而是隐含在代码位置里。/* 词法扫描核心最长匹配单字符回退位置维护 */ typedef enum { TK_ID, TK_NUM, TK_OP, TK_KW, TK_EOF, TK_ERR } TokKind; typedef struct { TokKind kind; int line, col; /* 报错定位的唯一起点必须准确 */ char text[64]; /* 词素原文超长截断由上层的长度检查兜住 */ int ival; /* 数值字面量的值 */ } Token; static int cur_line 1, cur_col 1; static FILE *src; /* 读一个字符并推进位置EOF 不推进 */ static int next_ch(void) { int c fgetc(src); if (c \n) { cur_line; cur_col 1; } else if (c ! EOF) cur_col; return c; } /* 回退一个字符缓冲区指针回退位置同步回退 */ static void unget_ch(int c) { if (c EOF) return; ungetc(c, src); cur_col--; /* 只回退列号跨行回退由调用方保证不发生 */ } Token scan(void) { Token t {0}; int c next_ch(); while (c || c \t || c \r || c \n) c next_ch(); t.line cur_line; t.col cur_col 0 ? cur_col - 1 : 0; if (c EOF) { t.kind TK_EOF; return t; } if (isalpha(c) || c _) { /* 标识符与关键字共用一条路径 */ int n 0; do { if (n 63) t.text[n] (char)c; c next_ch(); } while (isalnum(c) || c _); t.text[n] \0; unget_ch(c); /* 多读的那个字符必须还回去 */ t.kind is_keyword(t.text) ? TK_KW : TK_ID; return t; } if (isdigit(c)) { /* 数字吃满所有数字位再收 */ int v 0; do { v v * 10 (c - 0); c next_ch(); } while (isdigit(c)); unget_ch(c); t.kind TK_NUM; t.ival v; return t; } t.kind TK_OP; t.text[0] (char)c; t.text[1] \0; return t; /* 双字符运算符由 peek 在调用方补齐 */ }这段代码里值得掰开看的是三个地方。next_ch把位置维护内聚在唯一的读入口任何字符消费都经过它所以行列号不会因为某条分支忘了更新而漂移。unget_ch只回退列号这是一个刻意的约束它假设调用方不会回退换行符因为所有需要前瞻的场景都发生在同一行内把这条约束写进注释比写一堆防御分支更可靠。scan里的关键字判定放在吃满整个词素之后对应的是 2.1 里那个结论——关键字和标识符在自动机上不可分只能在接受态做二次判定。参数上text的长度上限要和文法里标识符的最大长度约定一致超长时是截断还是报错必须在实验报告里写清楚否则测试用例里出现超长标识符时输出会变成玄学。ival用int存数值意味着整数溢出不处理这在课程设计范围内是合理简化但要在报告里显式声明边界。至于错误 tokenTK_ERR不应该直接exit正确的做法是记录位置、跳过当前字符、继续扫描下一个 token把「一个非法字符导致整份源码只报一条错」变成「报出所有非法字符」——这是后面语法阶段能做错误恢复的前提。3. 语法分析递归下降为什么能吃掉 LL(1) 文法如果词法阶段解决的是「词素边界」语法阶段解决的就是「结构边界」一串 token 到底构成一个表达式、一条语句还是一整个程序。教科书从上下文无关文法讲到 FIRST/FOLLOW 集、再到 LL(1) 预测分析表看起来是一套完整的表驱动算法。但课程设计里绝大多数小型编译器用的是递归下降因为递归下降把「表」变成了「调用栈」把「查表选产生式」变成了「看当前 token 决定走哪个分支」调试时可以单步进到某个非终结符对应的函数里比对着压缩过的分析表猜要直观得多。3.1 FIRST 与 FOLLOW预测分析表的真实用途FIRST 集回答的是「这个符号串可能以哪些终结符开头」FOLLOW 集回答的是「这个非终结符后面可能跟哪些终结符」。在表驱动 LL(1) 里这两张集合起来决定M[非终结符, 终结符]填哪条产生式。而在递归下降里它们的用途变了FIRST 集决定每个解析函数的第一个if该判什么FOLLOW 集决定错误恢复时该跳到哪个同步记号。这个转换带来一个很实际的收益LL(1) 冲突检测可以提前做。如果同一个非终结符的两条产生式 FIRST 集相交那么这个文法不是 LL(1) 的递归下降写出来就会出现「两个分支都能进进去之后才发现走错」的回溯。课程设计里最常见的冲突来源是表达式文法的左递归和语句文法的公共前缀比如stmt - id expr | id(args)两条都以id开头不提取左公因子就没法用一次前瞻决定。实验报告里通常要求给出 FIRST/FOLLOW 集和预测分析表很多人把它当成形式化的作业步骤。其实它的真正价值在于表填不出来或者某一格有两个候选就说明文法有问题而这个问题在代码里表现为「莫名其妙地解析错」在没有表的情况下极难定位。先把表算出来等于给自己留了一颗后悔药。3.2 文法到函数的映射递归下降的代码骨架递归下降的映射规则简单到近乎机械每个非终结符一个函数函数体按产生式右部的顺序依次调用其他非终结符函数或匹配终结符。表达式文法的难点在于优先级和结合性标准做法是分层——每一层优先级对应一个函数层与层之间单向调用。/* 表达式解析三层递归下降层数即优先级 */ static Expr *parse_expr(void); /* 加减层左结合 */ static Expr *parse_term(void); /* 乘除层左结合 */ static Expr *parse_factor(void); /* 原子层num / id / (expr) */ static Expr *parse_expr(void) { Expr *left parse_term(); while (peek()-kind TK_OP (peek()-text[0] || peek()-text[0] -)) { Token op advance(); /* 消费运算符peek 与 advance 成对使用 */ Expr *right parse_term(); left new_binary(op.text[0], left, right); } return left; /* while 循环天然实现左结合 */ } static Expr *parse_factor(void) { Token t advance(); if (t.kind TK_NUM) return new_num(t.ival); if (t.kind TK_ID) return new_var(t.text); if (t.kind TK_OP t.text[0] () { Expr *e parse_expr(); expect()); /* 括号不匹配统一在 expect 里报错 */ return e; } error_at(t, unexpected token in expression); return new_num(0); /* 错误恢复产出占位节点继续解析 */ }while循环在这里承担了两件事一是消除左递归二是实现左结合。1-2-3在循环里会被折成(1-2)-3如果换成递归调用parse_expr自己就会变成右结合甚至无限递归。peek()和advance()的分工也要严格peek只看不动advance才推进输入所有「看一眼再决定」的地方都用peek避免出现「判断完了忘了消费」或者「消费了两次」这类经典错误。parse_term的结构和parse_expr完全同构只是运算符集合换成*/并且它的下层调用parse_factor。这种同构不是巧合它把「优先级」编码进了调用方向越靠近原子层的函数优先级越高。加一元负号或者幂运算时只要在正确的层插入新函数整条链路不用改。错误恢复那一行return new_num(0)也值得说。语法错误发生后如果直接exit后面的语义分析和代码生成全做不了实验报告里「错误处理」这一项就拿不到分。给定一个占位节点让解析继续后面的阶段会得到一棵部分正确的树至少能把剩余的语法错误也报出来。3.3 左递归与回溯三个必然翻车的位置第一个位置是直接左递归。E - E T | T写成函数是parse_E第一句就调parse_E栈立刻溢出现象是段错误而不是报错信息。解决办法就是 3.2 里那种迭代改写把左递归的产生式拆成「先解析一次右部再用 while 循环处理剩下的」。第二个位置是间接左递归和公共前缀。A - B x、B - A y这种互相调用的写法在文法里看起来没问题展开之后依然是左递归。公共前缀则表现为「两个分支都要先读同一个 token」递归下降没有回溯机制进去就出不来。这两类都要在文法层面改间接左递归先做代入消元公共前缀提取左公因子。第三个位置是错误恢复的同步集合。语法错误发生后如果只是简单跳过当前 token 继续很可能在错误的上下文里连报十几个错实验报告的输出会变得没法看。正确的做法是按 FOLLOW 集选同步记号——跳到语句结束的;或者块的}再恢复解析这样错误报告的数量大致等于真实错误的数量。这个策略实现起来不过十几行但对输出质量的影响非常大。4. 语义落地AST、符号表与三地址码是怎么串起来的词法和语法阶段产出的东西要么是一串 token要么是一棵语法分析树。语法分析树里保留了所有推导细节包括括号、分隔符、辅助非终结符这些东西对后续阶段毫无用处反而增加了遍历成本。所以中间表示的第一层压缩就是把语法分析树投影成抽象语法树只留下「值」和「结构」。4.1 AST 的节点设计为什么不是语法树的复制品AST 丢掉的是括号和分隔符保留的是运算优先级和求值顺序。(12)*3和12*3的语法分析树深度不同但投影成 AST 后前者的根节点是*、左子是后者的根节点也是*、右子是——括号信息已经编码进树的形状里不需要额外节点表示。节点结构有两种主流写法一种是统一struct加kind标签加union另一种是每种节点一个独立struct加基类指针。课程设计里前者更常见因为它省内存、遍历时也少一层跳转。typedef enum { N_NUM, N_VAR, N_BIN, N_ASSIGN, N_IF, N_WHILE, N_BLOCK } NodeKind; typedef struct Node { NodeKind kind; /* 标签决定 union 里哪个成员有效 */ int line; /* 语义阶段的报错也要能指回源码 */ union { int ival; /* N_NUM */ char name[64]; /* N_VAR / N_ASSIGN */ struct { struct Node *l, *r; char op; } bin; /* N_BIN */ struct { struct Node *cond, *then, *els; } ctl; /* N_IF / N_WHILE */ struct { struct Node *item[64]; int n; } blk; /* N_BLOCK */ } u; } Node;line字段看起来是冗余的因为 token 里已经有位置了。但语义阶段的错误未声明变量、类型不匹配是在遍历 AST 时发现的那时候 token 早就没了只剩节点。每个节点存一份行号语义报错才能指回源码。这是我在课程设计里吃过亏之后加上的字段——最初没存结果所有语义错误只能报「发生了类型错误」完全没法定位。union的代价是必须靠kind分发访问错成员不会报编译错误只会得到垃圾值。常见的做法是写一组访问器函数as_bin(n)、as_num(n)在里面assert(n-kind ...)把所有不安全的访问收敛到一处。4.2 符号表作用域链与哈希桶的选择符号表要回答两个问题这个名字在当前作用域可见吗它是什么类型、放在哪第一个问题决定结构第二个问题决定字段。作用域是嵌套的块进入时开新作用域、离开时销毁天然对应一个栈但查找要沿着作用域链往上走所以要给每个作用域存一个父指针。typedef struct Sym { char name[64]; SymType type; int slot; /* 分配到的存储位置编号代码生成时用 */ struct Sym *next_in_scope; /* 同一作用域的链表 */ } Sym; typedef struct Scope { Sym *syms; struct Scope *parent; } Scope; /* 从内向外逐层查找实现内层遮蔽外层 */ Sym *lookup(Scope *s, const char *name) { for (; s; s s-parent) for (Sym *p s-syms; p; p p-next_in_scope) if (strcmp(p-name, name) 0) return p; return NULL; }作用域内的符号用链表串起来而不是哈希桶是因为课程设计里单个作用域的符号数量通常只有个位数到几十个链表遍历的开销可以忽略而链表换来了「按声明顺序遍历」这个能力——代码生成阶段要按声明顺序给局部变量分配槽位链表天然是有序的。符号数量上千时再换成哈希桶加链表接口不用变。lookup逐层向外查找的顺序决定了遮蔽语义内层声明同名变量后外层那个在块内不可见但离开块之后又恢复可见。这个行为靠parent链和「离开作用域时丢弃整个Scope结构」共同实现。要注意的是如果代码生成阶段还需要知道内层变量的信息比如生成块结束时的清理代码就不能真的free掉Scope得改成压栈出栈的数组结构。4.3 三地址码生成临时变量与标号的管理三地址码的形态是x y op z每条指令最多一个运算符、最多三个地址。从 AST 生成三地址码是一个后序遍历先递归求出子表达式的「值名」再为当前节点生成一条指令返回一个新临时变量名。static int temp_cnt 0; static int new_temp(void) { return temp_cnt; } /* t1, t2, t3 ... */ /* 统一输出口所有指令都从这里打印便于后面统一格式化 */ static void gen(const char *fmt, ...) { va_list ap; va_start(ap, fmt); vprintf(fmt, ap); va_end(ap); putchar(\n); } /* 返回子表达式的值名字面量返回原文变量返回名字运算返回新临时变量 */ void emit_expr(Node *n, char *out, size_t cap) { if (n-kind N_NUM) { snprintf(out, cap, %d, n-u.ival); return; } if (n-kind N_VAR) { snprintf(out, cap, %s, n-u.name); return; } if (n-kind N_BIN) { char l[64], r[64]; emit_expr(n-u.bin.l, l, sizeof l); /* 各自独立的缓冲区绝不共用 */ emit_expr(n-u.bin.r, r, sizeof r); snprintf(out, cap, t%d, new_temp()); gen(%s %s %c %s, out, l, n-u.bin.op, r); return; } snprintf(out, cap, 0); }这里最关键的设计是out由调用方提供缓冲区。早期版本我用static char buf[64]在函数内部返回指针结果左子表达式和右子表达式拿到的是同一块内存生成的指令变成t1 t2 t2——两个操作数永远相同。这个 bug 在简单用例里不一定暴露只有嵌套表达式才会现形属于典型的黑匣子式错误。临时变量用全局计数器自增好处是编号唯一、不会和作用域里的用户变量重名前提是用户标识符不允许以t加纯数字的形态出现这一点要在词法规则里约定。标号同理while和if各需要两三个标号用L1、L2递增生成。麻烦的地方在于「回填」生成条件跳转时跳转目标地址还不知道得先留空等目标代码生成完再补上。课程设计里最常见的简化做法是先把整个结构走一遍、分配好标号第二遍再真正生成指令——多一遍遍历换来代码逻辑简单一个量级。5. 排查清单课程设计里最容易翻车的四类问题编译器的输出是一长串结构化文本出错时的现象往往和原因隔了好几层靠打印中间结果硬猜效率极低。下面这几条按「现象 → 原因 → 解决」整理基本都是我在写小型编译器时真实撞过的。5.1 词法与语法阶段报错位置全歪、栈直接溢出现象一a b被解析成a (b)或者直接报「非法字符」。原因是双字符运算符没有做前瞻读到就立刻返回被当成独立的运算符。解决方法是把所有多字符运算符集中在一张前缀表里读到第一个字符后统一peek一次命中组合就advance两个字符否则只消费一个。别在switch的每个分支里各写一遍前瞻逻辑那样漏掉一个组合很难发现。现象二报错信息里的行号普遍偏一行尤其是在块注释跨行或者文件末尾有换行时。原因是unget_ch回退了字符但没回退位置计数器或者注释处理函数自己用fgetc读字符、绕过了next_ch。解决方法是规定所有字符读写必须走同一对next_ch/unget_ch注释处理也走这条路径并且在文件末尾统计一次总行数做交叉验证。现象三解析稍长的表达式时直接段错误没有报错信息。原因是文法里存在直接左递归或间接左递归递归下降写出来就是无限调用自身。解决方法是先用一个小脚本把文法展开一遍检查是否存在某个非终结符能推导出以自己开头的串有的话先做消除左递归和提取左公因子再动手写函数。5.2 语义与输出比对更隐蔽的两类错误现象四三地址码里t1 t2 t2两个操作数莫名其妙相同但语法树打印出来是对的。原因是求值函数内部用了static缓冲区返回字符串两次递归调用拿到的是同一块内存。解决方法是让调用方传缓冲区进来或者返回一个由调用方负责释放的堆字符串更彻底的做法是给每个临时值一个 ID输出阶段再统一格式化。现象五本地跑出来的结果和实验报告要求完全一致一提交就 diff 全红。原因是行尾空格、末尾多余换行、临时变量编号从 0 还是从 1 开始这类格式细节没有统一。解决办法是把输出格式抽成一组常量并且自己写一个比对脚本把空白规范化之后再 diff而不是靠肉眼比。格式这种东西一旦靠肉眼翻车是迟早的。6. 设计取舍一个「不完整」的小型编译器为什么反而更值得读课程设计里的小型编译器通常不做优化、不做完整的类型系统、错误恢复只做到「不崩」。很多人觉得这是能力不足的妥协但从设计角度看这些省略恰恰是让整条链路可理解的关键。最典型的取舍是遍数。真实的编译器是多遍的前端产出 IR、中端做优化、后端做指令选择与寄存器分配。每一遍之间用文件或内存结构解耦好处是每一遍都能独立测试坏处是任何一次改动都要跨越多个数据结构。课程设计的小型编译器一般是两遍——先建 AST再直接生成三地址码——甚至可以在遍历 AST 的同时就打印指令。这种做法的代价是不能做需要全局信息的事情比如常量传播、死代码消除收益是数据流只在一个方向流动任何一条输出都能立刻追溯到某个节点。第二个取舍是错误恢复的深度。完整的编译器要保证「任何输入都不崩溃、并且报出所有能报的错」这需要为每个非终结符定义同步集合、在语义阶段做错误节点的传播抑制。课程设计里通常只需要保证「合法输入正确、常见非法输入有提示」于是同步集合只覆盖语句边界语义错误也只报第一个。这不是偷懒而是把精力放在可验证的部分上实验报告里能给出测试用例、能说明每条用例覆盖了哪条产生式或哪条语义规则比堆一堆半成品的恢复逻辑更有说服力。第三个取舍是中间表示的层数。从 token 到 AST 到三地址码每一层都是一次信息压缩每一次压缩都丢掉一些东西。AST 丢掉了括号三地址码丢掉了嵌套结构。压缩得越早后续阶段越简单但调试时能看到的细节也越少。我一般会保留一个「打印 AST」的开关出问题时先把树打出来确认结构和预期一致再去怀疑代码生成。这个开关本身只有几十行却能省掉大量猜谜时间。如果要把这套东西读透建议的顺序是反过来的先看三地址码的输出格式反推每个临时变量是由哪个 AST 节点产生的再看那个节点在语法分析里由哪条产生式构造最后看这条产生式依赖哪些 token。从输出倒推回词法规则整条链路的设计动机就串起来了——每一层都在为下一层准备「恰好够用」的信息多一分是浪费少一分就断链。从那以后我每次写任何解析器都强制先手画一遍从输入到输出的数据流确认每个阶段手里握着什么、缺什么再开始写第一行代码。希望帮到你。本文还有配套的精品资源点击获取

从词法分析到三地址码：小型编译器的链路与避坑

相关推荐

CTF竞赛中隐蔽题型解析与实战技巧

离网混合储能系统容量优化与粒子群算法应用

从词法分析到四元式：小型编译器三段流水线实现与调试

更多资讯

RT-DETR轻量化优化：知识蒸馏在目标检测中的应用

工程设计企业AI落地四阶段实施路径与关键技术

SuperScan 实战指南：老旧 Windows 环境下的内网扫描与资产梳理

SuperScan 使用教程：老 Windows 环境下的端口扫描与主机发现实战

UOS运维工程师题库高频考点：端口、配置路径与命令参数详解

Oracle冷门视图V$QPX_INVENTORY：并行执行子系统组件清单解析

今日更新

学生选课系统DFD图绘制指南：边界划分与分层校验实战

JIRA敏捷落地：Scrum角色权限、Sprint与燃尽图避坑指南

SEMI S8人机工程验收实战：从条款拆解到现场实测的完整指南

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？