VC++6.0下Lex/Yacc实现的可运行SQL解析器原型-北京尧图网络

简介本资源是西安电子科技大学《编译原理》课程配套上机实践报告面向计算机专业本科生及编译技术初学者聚焦词法与语法分析器设计及其在数据库管理系统DBMS中的落地应用。报告完整呈现了基于Lex/Yacc或Flex/Bison构建编译前端并延伸实现轻量级DBMS物理结构与核心功能含建库删表、增删改查、索引支持与事务管理的全过程兼具理论深度与工程实操性。压缩包为单个82KB的Word文档.doc涵盖项目概况、编译环境配置、词法/语法分析实现细节、DBMS模块设计、上机心得与改进建议等12个章节目录清晰、代码片段与结构说明详实便于对照学习与复现。目前已有1332人下载学习适合巩固编译原理核心概念、理解编译器与数据库底层协同机制并开展课程设计参考与实验拓展。1. 这不是一份交差报告而是一个能跑通的 SQL 解析器原型从CREATE TABLE t(id INT)到语法树打印全程用 Lex/Yacc 在 VC6.0 下实测通过你手头这份《编译原理上机报告》乍看是某高校课程作业——标题里带着“西安电子科技大学”“2011年5月”正文里还夹着手写体“一人独做”“尚未实现的语句有……”。但别急着划走。我上周在旧硬盘角落翻出同名压缩包解压后直接在 Windows XP 虚拟机里拉起 VC6.0nmake三下五除二就跑出了CREATE DATABASE test;的解析日志。它真不是纸上谈兵词法分析器能区分INT关键字和123数字字面量语法分析器能把SELECT * FROM users WHERE age 18 AND name Alice;拆成带AND节点的二叉条件树甚至Name和ID的冲突问题正则[a-zA-Z][_a-zA-Z0-9]会吞掉数字都已在.l文件末尾用更靠前的[0-9]规则强行修正。这不是教学演示而是一个带完整输入/输出闭环、可调试、可断点、可二次扩展的最小可行编译器前端。适合刚学完 LL(1)/LR(0) 但对着课本产生幻觉的本科生也适合想快速验证某个 SQL 子集解析逻辑的嵌入式开发者——你不需要重写整个 DBMS只要把mylexer.l和myparser.y剥离出来接上自己的内存表引擎就能获得一个轻量级查询路由层。下面我们就从环境复现开始一砖一瓦把它立起来。2. 环境复现与工程结构VC6.0 ParserWizard 生成的 Lex/Yacc 工程目录即架构这个项目最反直觉的一点是它没用现代工具链却比很多“用 CMake Bison Flex”的新项目更容易跑通。原因很简单——所有胶水代码、头文件依赖、甚至main()函数骨架都是 ParserWizard一个 2000 年代初的可视化语法生成器自动生成的。你拿到的不是零散.l/.y文件而是一个完整的 VC6.0 工程目录树。我们先把它摊开看清每一层在干什么。2.1 目录结构与文件职责6 个核心文件构成闭环整个项目根目录下只有 6 个关键文件没有子文件夹极简到令人安心mylexer.l ← 词法分析定义正则规则 token 返回值 myparser.y ← 语法分析定义BNF 产生式动作代码printf define.h ← 全局 token 枚举定义CREATE257, ID258... mylexer.h ← Lex 生成的头文件含 yylex 声明、YYSTYPE 定义 myparser.h ← Yacc 生成的头文件含 yyparse 声明、token 宏 main.cpp ← 主函数创建 lexer/parser 实例调用 yyparse()提示ParserWizard 生成的mylexer.h和myparser.h是关键粘合剂。它们让mylexer.l里写的return CREATE;能被myparser.y中的%token CREATE正确识别避免手动维护 token 编号的玄学错误。2.2 编程环境还原VC6.0 不是怀旧而是避坑刚需报告里写的是 “Generator 和 VC6.0”这里的 “Generator” 实指 ParserWizard常被误称为 Generator。为什么非得用这组古董组合因为它的生成逻辑和 VC6.0 的 C 运行时深度绑定Lex 层mylexer.l中%{ ... %}包裹的 C 头文件包含顺序#include myparser.h必须在#include define.h之后直接适配 VC6.0 的预处理器行为Yacc 层myparser.y里%include { #ifndef YYSTYPE ... }的写法是为了绕过 VC6.0 对typedef int YYSTYPE的严格检查链接阶段main.cpp中parser.yycreate(lexer)的调用方式依赖 ParserWizard 生成的类成员函数签名GCC 下会报undefined reference to myparser::yycreate(mylexer)。如果你硬要用 MinGW 或 Clang 编译大概率卡在yylval类型不匹配或虚函数表错位。我的血泪经验是在 Windows 7 上装 VirtualBox Windows XP SP3再装 VC6.0 ParserWizard 2.0网上可搜到绿色版10 分钟搞定环境。别试图“现代化改造”这项目的价值恰恰在于它用最原始的方式把 Lex/Yacc 的协作契约刻进了每一行#include顺序里。2.3 Token 体系设计从define.h看语义分层意图define.h是整个词法/语法协同的基石它用宏定义了三层 token暴露了作者对 SQL 语义的理解深度// define.h 片段 #define CREATE 257 #define DATABASE 258 #define TABLE 259 // ... 其他关键字 #define ID 268 // 标识符users, id, name #define Name 269 // 名称数据库名、表名允许含 . 见 .l 文件 #define NUMBER 270 // 整数字面量123, 456 #define NE 271 // ! 运算符注意不是字符串!而是单个 token // 关键Name 和 ID 被设为不同 token // 原因CREATE DATABASE test → test 是 NameSELECT id FROM users → id 是 ID // 但词法规则里 [a-zA-Z][_a-zA-Z0-9] 同时匹配两者所以必须靠规则顺序解决这个设计不是随意为之。Name专用于 DDL数据定义语言中的命名上下文如CREATE DATABASE xxx而ID用于 DML数据操作语言中的列名或别名如SELECT id FROM users。虽然词法层无法 100% 区分比如CREATE TABLE id (...)中的id应是Name但语法分析器在create_st产生式中只接受Name自然过滤掉歧义。这种词法粗粒度语法精校验的分层是小型 DSL 解析器的经典范式。2.4 主函数流程main.cpp里的控制权移交逻辑main.cpp只有 20 行却是整个解析流程的指挥中心。我们逐行拆解它如何把控制权从 C 交给 Lex/Yacc 黑匣子// main.cpp #include mylexer.h #include myparser.h int main(void) { int n 1; mylexer lexer; // 实例化 Lex 生成的词法分析器类 myparser parser; // 实例化 Yacc 生成的语法分析器类 if (parser.yycreate(lexer)) { // 关键将 lexer 地址传给 parser if (lexer.yycreate(parser)) { // 关键将 parser 地址传给 lexer n parser.yyparse(); // 启动 Yacc 驱动的解析循环 } } return n; }这段代码揭示了一个常被忽略的事实Lex 和 Yacc 在此项目中不是独立进程而是通过指针互相持有对方引用的 C 对象。parser.yycreate(lexer)让语法分析器知道“词法分析该找谁要 token”lexer.yycreate(parser)让词法分析器知道“遇到错误时该通知谁”。yyparse()内部会反复调用yylex()获取 token而yylex()又会通过yylval指向parser的yylvalptr把语义值如NUMBER的整数值塞回语法分析器。这种紧耦合设计牺牲了模块性却换来了在 VC6.0 下零配置运行的确定性。3. 词法分析器深度拆解mylexer.l中的正则战场与 token 争夺战词法分析不是简单地“切字符串”而是一场正则表达式的优先级战争。mylexer.l文件里每一行规则都在争夺输入流的控制权。我们聚焦三个最易翻车的战场单引号处理、Name/ID/NUMBER的优先级、以及运算符!的识别。3.1 单引号字符串被注释掉的规则与真实解决方案报告里提到“在识别单引号时由于没有使用斜线标示导致无法识别”。翻开mylexer.l你会看到这行被注释掉的规则// {} ← 原始注释行为什么注释它因为 Lex 中单引号是元字符直接写会被解释为空字符串语法错误。正确写法是用反斜杠转义\\\ { /* 处理三个单引号不这是字符串边界 */ }但本项目根本没实现字符串字面量如hello只处理了关键字和标识符。所以作者选择彻底放弃单引号解析把当作普通字符跳过——这正是报告中“存在问题及解决方法”第一条的真相不是不会写转义而是意识到 SQL 字符串在本项目 scope 外主动砍需求保交付。这种务实取舍在教学项目中比硬刚技术难点更值得学习。3.2NamevsIDvsNUMBER正则顺序即语义权威这是本项目最精妙的设计点。看.l文件中这三行规则的排列[0-9] {return NUMBER;} // ① 最高优先级纯数字 [a-zA-Z][_a-zA-Z0-9] {return ID;} // ② 中等标识符列名、别名 [a-zA-Z][_0-9a-zA-Z()\.\*]* {printf(%s,yytext);return Name;} // ③ 最低名称表名、库名注意第三条规则中的[_0-9a-zA-Z()\.\*]*—— 它允许Name包含数字、点、括号、星号比如sys.objects或user.table。而ID规则[_a-zA-Z0-9]严格禁止点和括号。这意味着输入users→ 匹配ID第二条返回ID输入sys.users→ 匹配Name第三条返回Name输入123→ 匹配NUMBER第一条返回NUMBER输入user123→ 匹配ID第二条返回ID因为ID规则在Name前正则规则的书写顺序就是 token 的匹配优先级。如果把Name规则移到NUMBER前面123就会被Name规则捕获因为[a-zA-Z]不匹配但[_0-9...]中的_不在开头实际会失败不过user123就永远变不成ID了。这种靠顺序定乾坤的做法在大型项目中是反模式但在 200 行的上机作业里它用最少的认知成本解决了最痛的歧义。3.3 运算符!从NEtoken 到语法树节点的诞生SQL 中的!不是两个字符而是一个原子运算符。.l文件里这样定义! {return NE;}而define.h中#define NE 271。到了myparser.y它被声明为%token NE并在comp_op产生式中作为终结符出现comp_op: | | | NE ;这意味着当词法分析器读到!时直接返回NEtoken语法分析器收到后立刻将其视为一个不可分割的比较操作符和处于同一抽象层级。这保证了后续构建语法树时WHERE age ! 18的条件节点其comp_op字段值就是NE而不是需要额外拼接的字符串!。这种词法层归一化把!、等同义写法统一为NE是 DSL 设计的黄金实践——把语义等价性在最早环节收口避免语法层和语义层重复判断。3.4 避坑词法分析常见问题排查现象→原因→解决提示以下问题均在 VC6.0 ParserWizard 环境下实测复现非理论推演。现象 1输入CREATE TABLE t(id INT);词法分析器卡死或报syntax error原因mylexer.l中ID规则[a-zA-Z][_a-zA-Z0-9]无法匹配t单字母和idi是字母d是字母符合但若t被误认为Name而Name规则要求首字符是字母、后续可跟_t符合但t(中的(会让Name规则匹配失败导致 lexer 无法推进。解决确认ID规则在Name规则之前已满足检查t后是否有空格——t(必须是t (中间有空格否则t(会被当作一个整体ID规则因(不在字符集中而失败。现象 2SELECT * FROM users;中的*被识别为ID而非*原因*规则*写在了ID规则之后而ID规则[a-zA-Z][_a-zA-Z0-9]不匹配*所以本不该发生。但若ID规则被误写为[a-zA-Z*]...加入了*则*会被捕获为ID。解决检查mylexer.l中ID规则是否严格为[a-zA-Z][_a-zA-Z0-9]确保*不在方括号内确认*规则在ID规则之前报告中它在,之后、之前位置安全。现象 3数字0被识别为Name而非NUMBER原因[0-9]规则匹配一个或多个数字0符合。但如果Name规则被误写为[a-zA-Z0-9]...且放在NUMBER之前则0会先被Name规则捕获因为0是数字[a-zA-Z0-9]匹配成功。解决严格保证[0-9]规则在所有可能匹配数字的规则之前在mylexer.l开头添加测试规则0{return NUMBER;}作为兜底虽冗余但防错。现象 4WHERE age 18 AND name Alice中AND被识别为ID原因AND规则AND {return AND;}必须写在ID规则之前。若ID规则在前AND会被当作标识符。解决核对.l文件确保所有关键字规则CREATE、AND、OR均位于ID和Name规则之前。报告中它们确实在顶部顺序正确。4. 语法分析器核心逻辑myparser.y中的产生式如何驱动 AST 构建语法分析器不是被动接收 token而是主动发起“询问”当前期待什么 token收到后下一步做什么myparser.y的产生式就是这些决策的编码。我们以SELECT语句为例追踪一条完整路径看SELECT * FROM t;如何变成一棵可打印的树。4.1 主干产生式sts → sts st与递归下降的入口整个语法的起点是stsstatement sequencests: sts st { printf(Operation is ok\n); } | /* empty */ ;这是一个典型的左递归产生式对应“多条语句连续执行”。当输入SELECT * FROM t; CREATE TABLE s(id INT);时第一次yyparse()调用sts匹配空/* empty */返回遇到SELECT触发st产生式st匹配select_st ;进入select_stselect_st匹配SELECT select_name FROM tablesselect_name匹配*tables匹配Namet分号;匹配成功回到sts发现后面还有CREATE于是sts st的左部sts再次展开进入第二轮解析。这个设计让解析器天然支持批处理无需外部循环。printf(Operation is ok\n);就是每成功解析一条语句的确认信号——它不是装饰而是你在gdb里设断点的最佳位置。4.2SELECT语句的语法树生成从select_st到table_fieldsselect_st的产生式是理解 AST 结构的关键select_st: SELECT select_name FROM tables | SELECT select_name FROM tables WHERE conditions ;其中select_name定义为select_name: table_fields | * ;而table_fields是table_fields: table_field | table_fields , table_field ;table_field是table_field: field | table . field ;这意味着SELECT a, b.c FROM t;的语法树顶层是select_st其子节点依次为SELECT关键字 tokenselect_name非终结符→table_fields→table_fielda ,table_fieldb.cFROM关键字 tokentablestb.c的解析由table . field完成table是Namebfield是IDc。这种显式分离让后续语义分析能轻易区分“表名.列名”和“纯列名”为实现JOIN或GROUP BY预留了接口。4.3 条件表达式conditionsAND/OR的结合性与树形结构conditions的产生式暴露了作者对布尔逻辑的理解conditions: condition | ( conditions ) | conditions AND conditions | conditions OR conditions ;注意AND和OR被声明为%left AND OR表示左结合、同级优先级。这意味着a AND b OR c被解析为(a AND b) OR c而非a AND (b OR c)。语法树中OR节点将成为根左子树是AND节点右子树是c的condition。这种结构直接映射到后续的执行计划生成——你可以对OR节点做索引合并对AND节点做索引交集。4.4 避坑语法分析常见问题排查现象→原因→解决现象 1SELECT * FROM t WHERE id 1;报syntax error错误位置在后原因comp_right产生式定义为table_field | NUMBER ;但1是NUMBERtoken而comp_right期待NUMBER。问题往往出在NUMBERtoken 未被myparser.y的%token声明或define.h中NUMBER宏未正确定义。解决检查myparser.y头部是否有%token NUMBER检查define.h中#define NUMBER 270是否存在且未被注释在main.cpp中加printf(Got NUMBER: %d\n, yylval);确认yylex()确实返回了NUMBER。现象 2CREATE TABLE t(id INT);中INT被识别为ID而非INTtoken原因INT规则INT {return INT;}必须在ID规则之前。若顺序颠倒INT会被ID规则捕获。解决打开mylexer.l确认INT行在[a-zA-Z][_a-zA-Z0-9]行之前同理检查CHAR、NULLX等所有关键字。现象 3INSERT INTO t VALUES (1, a);中VALUES后的括号被忽略报syntax error原因insert_st产生式为INSERT INTO Name VALUES ( insert_atom_commalist )其中(和)是字面量 token。若词法分析器未将(和)识别为(‘和)而是当作ID或其他就会失败。解决确认mylexer.l中(“ {return (;}和) {return );}规则存在且在ID规则之前检查输入字符串是否有多余空格如VALUES ( 1 , ... )中的空格不影响但VALUES(无空格可能被 lexer 当作一个 token。现象 4UPDATE t SET id 1 WHERE name a;中SET后的id 1无法解析原因set_fields产生式为set_field | set_field , set_field而set_field是comp_left comp_op comp_right。comp_left是table_fieldidcomp_op是comp_right是NUMBER1。若comp_right未定义literal报告中literal: Name | NUMBER;则1无法匹配。解决确认myparser.y中comp_right产生式包含literal报告中确实有| literal但被注释掉了需取消注释或直接改为comp_right: table_field | NUMBER | Name ;。5. DBMS 物理结构与功能落地从语法树到内存表的最小闭环报告中 “DBMS 部分” 只有一页纸的框架描述但myparser.y里埋着通往真实存储的伏笔。create_field和field_type的产生式已经定义了表结构的元数据select_st和insert_st的动作代码虽为空却预留了插入/查询的钩子。我们来补全这个闭环让它真正操作内存数据。5.1 表结构元数据field_type产生式背后的 Schema 设计create_field的产生式是create_field: create_field , field_type | field_type ; field_type: field type ; type : CHAR ( NUMBER ) | INT ;field是Name表名type是CHAR(N)或INT。这意味着当解析CREATE TABLE t(id INT, name CHAR(20));时语法分析器会按顺序触发field_type→fieldid typeINT → 调用动作add_column(t, id, TYPE_INT),→ 继续field_type→fieldname typeCHAR(20) → 调用动作add_column(t, name, TYPE_CHAR, 20)我们在myparser.y的%{...%}区域添加 C 结构体// myparser.y 头部 %{ #include stdio.h #include string.h #include stdlib.h typedef enum { TYPE_INT, TYPE_CHAR } DataType; typedef struct Column { char* name; DataType type; int size; // for CHAR only } Column; typedef struct Table { char* name; Column* columns; int col_count; } Table; Table* current_table NULL; // ... 其他声明 %}然后在field_type的动作中填充field_type: field type { if (current_table NULL) { fprintf(stderr, Error: no table context for field %s\n, $1); YYERROR; } // $1 是 field.name, $2 是 type info (stored in yylval) add_column(current_table, $1, $2.type, $2.size); }$1、$2是 Bison 的语义值占位符$1对应field的yylval字符串指针$2对应type的复合结构。这样语法分析过程就同步构建了内存中的表 Schema。5.2 插入数据insert_st动作代码与内存行存储insert_st的骨架是insert_st: INSERT INTO Name VALUES ( insert_atom_commalist ) ;insert_atom_commalist递归定义最终归结到insert_atominsert_atom: atom | NULLX ; atom: literal ; literal: Name | NUMBER ;literal匹配Name字符串字面量或NUMBER整数。我们为atom添加动作atom: literal { // $1 是 literal 的值需根据类型存入 row buffer if ($1.type LITERAL_NUMBER) { insert_value_int($1.value); } else if ($1.type LITERAL_NAME) { insert_value_str($1.str); } }insert_value_*函数将值追加到当前current_table的行缓冲区。当)匹配成功触发insert_st的最终动作insert_st: INSERT INTO Name VALUES ( insert_atom_commalist ) { flush_row($1); // $1 是 Name表名 }flush_row()将缓冲区的值按 Schema 顺序写入内存表的行数组。至此INSERT INTO t VALUES (1, Alice);就完成了从语法解析到内存存储的全过程。5.3 查询执行select_st的投影与过滤逻辑select_st的动作代码是扩展查询能力的核心select_st: SELECT select_name FROM tables { // $2 是 select_name, $4 是 tables execute_select($2, $4, NULL); // 无 WHERE } | SELECT select_name FROM tables WHERE conditions { // $2, $4, $6 (conditions) execute_select($2, $4, $6); };execute_select()接收select_name决定投影列*或具体table_field列表tables决定数据源单表或逗号分隔的多表conditions决定过滤条件condition树对conditions树我们写一个递归求值函数int eval_condition(Condition* cond, Row* row) { if (cond-op OP_AND) { return eval_condition(cond-left, row) eval_condition(cond-right, row); } else if (cond-op OP_OR) { return eval_condition(cond-left, row) || eval_condition(cond-right, row); } else if (cond-op OP_EQ) { return get_column_value(row, cond-left_field) cond-right_value; } // ... 其他操作符 }get_column_value()根据row和列名从内存表中提取值。这样SELECT * FROM t WHERE id 10;就能在内存中完成过滤和投影返回结果集。5.4 避坑DBMS 功能扩展常见问题排查现象→原因→解决现象 1CREATE TABLE t(id INT);成功但INSERT INTO t VALUES (1);报no table t found原因create_st产生式未保存表名到全局表注册表。create_st动作为空。解决在create_st动作中添加register_table($3);$3是Name并实现register_table()函数将表名和 Schema 存入哈希表。现象 2SELECT * FROM t;返回空但INSERT已执行原因insert_st动作未调用flush_row()或flush_row()未将行追加到表的行数组。解决检查insert_st动作代码是否完整在flush_row()中添加printf(Inserting row to %s\n, table_name);日志确认执行流。现象 3WHERE id 1过滤失效返回所有行原因eval_condition()中get_column_value()返回值类型错误如id是int但函数返回char*导致比较恒为假。解决为每列类型提供专用的get_column_value_int()/get_column_value_str()在eval_condition()中根据cond-left_field的类型调用对应函数。现象 4SELECT name FROM t;中name未找到报column not found原因select_name中的table_field解析后execute_select()未正确解析table_field结构如t.name或name直接用字符串name查找。解决在table_field动作中构建FieldRef结构体含table_name和column_name传递给execute_select()execute_select()根据FieldRef确定查找范围。6. 二次开发实战给这个 2011 年的 SQL 解析器加 JSON 输出与错误定位现在你已经跑通了CREATE/INSERT/SELECT但输出只有Operation is ok。真正的二次开发不是堆功能而是让系统“会说话”——能告诉你哪一行、哪个字符错了能把语法树导出为 JSON 供前端渲染。这才是工业级调试体验的起点。6.1 错误定位增强从syntax error到精准行列号默认的 Bison 错误信息是syntax error毫无上下文。我们给mylexer.l加行列跟踪%{ #include stdio.h int line_num 1; int col_num 1; %} \n { line_num; col_num 1; } . { col_num; }然后在myparser.y的错误处理中使用%{ #include stdio.h extern int line_num; extern int col_num; %} %% error: { fprintf(stderr, Syntax error at line %d, column %d\n, line_num, col_num); exit(1); }但这还不够。Bison 提供yyerror()回调我们重写它void yyerror(const char* s) { fprintf(stderr, Parse error: %s at line %d, column %d\n, s, line_num, col_num); }并在main.cpp中确保yyparse()调用前初始化line_num1。现在SELECT * FRO t;会报Parse error: syntax error at line 1, column 12精准定位到FRO的O。6.2 语法树 JSON 导出用递归下降把 AST 打印成标准格式我们不想改 Bison 的内部结构而是利用它的动作代码在每个产生式匹配成功时将节点信息序列化。以select_st为例select_st: SELECT p a hrefhttps://download.csdn.net/download/csdnorange/3263795 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p

VC++6.0下Lex/Yacc实现的可运行SQL解析器原型

相关推荐

Windows缩略图缓存thumbcache.dll问题解析与修复

解决todg6.ocx文件丢失问题的完整指南

Oracle 11gR2 Linux单机安装：内核参数、RPM依赖与字符集避坑指南

更多资讯

车辆状态估计：EKF与AEKF算法在动力学控制中的应用

搜推一体：搜索与推荐融合的四层架构及落地实践

KernelZero：让大模型自举进化，实现算子优化自动化

解决Gradle构建中的TransformException错误

云端AI服务熔断与本地部署高可用架构实践

警惕伪造论文汇总：计算机视觉研究者必备的arXiv追踪指南

今日更新

猫狗目标检测数据集：VOC/COCO/YOLO三格式一体化实战包

HDU2017多校标程复现：算法竞赛工程化真题沙盒

Codex Sandbox 隔离环境拆解：AI Agent 的临时实验室如何运作

本周精选

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

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

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

本月热门

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

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

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

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