简繁汉字库MySQL建表、导入与按笔画排序实践-北京尧图网络

简介这份面向汉字信息化处理、教学与开发场景的MySQL数据包围绕简繁汉字的笔画数、笔顺、Unicode及GB编码等字段组织数据可服务于汉字输入法、姓名与诗词笔画统计、书法教学、字符检索等需求。压缩包为rar格式内含1个SQL文件整体约304KB可直接在MySQL环境中导入建表并进行查询分析。已有980人学习说明其在汉字数据处理方向具有一定参考价值。数据覆盖简体与繁体汉字便于读者按笔画数、笔顺或编码快速筛选目标字符也为旧GB编码与Unicode标准之间的兼容处理提供基础对于需要搭建汉字字典表、开展文字统计或验证编码映射的开发者与研究者可减少基础数据整理成本快速进入查询与应用开发环节。1. 从一张“按笔画查字”的慢查询说起这份简繁汉字库到底解决什么做内容后台的人大多遇到过这种需求按汉字笔画给姓名、词条或标签排序结果“龘”跑到“一”前面前端还显示成问号。汉字笔画及 Unicode 数据库简繁MySQL 就是把这个需求落成一张可查询的基础表每个字符对应码点、笔画数、部首、简繁关系和常用度适合做字典、姓名排序、生僻字校验、古籍整理和搜索联想。它不是一份字典附录而是业务库里的维度表新手能照着建表导入熟手更关心简繁非一一对应、扩展区码点和排序稳定性。下面按我拆库的顺序把表结构、导入、查询和踩坑一次讲透。2. 拆开简繁字库三张表、码点字段与建表 DDL2.1 为什么不是一张表塞完字符主表与笔画属性表拿到一份“汉字笔画及 Unicode 数据库简繁MySQL”资源第一眼不要急着找ORDER BY语句。先把表拆开看字符主表负责码点和字形属性表负责笔画、部首、结构、拼音简繁映射表负责一对多关系。很多资源为了导入方便会给一张宽表字段从码点一路排到繁体字短平快但一接业务就露馅同一个简体字对应两个繁体字时宽表要么重复行要么只留一个值后面做简繁转换就会把“发”统一成“發”把“头发”转成“头發”。我一般会按下面三张表来落表作用关键字段唯一键hanzi_char字符主表一个码点一行codepoint、ch、block_name、is_commoncodepoint、chhanzi_attr笔画与部首属性stroke_count、radical、radical_order、structure、pinyincodepointhanzi_variant简繁与异体映射simp_codepoint、trad_codepoint、relation_type(simp_codepoint, trad_codepoint)这么拆的理由不复杂。码点是 Unicode 里最稳定的主键字符本身反而可能因为异体字、兼容区字形不同而出现重复笔画数、部首、拼音属于可修订属性单独一张表方便你换口径、补来源简繁映射天然是多对多不能硬塞进一个trad_char字段。资源包如果只给单表至少也要保证codepoint唯一并且把简繁关系拆成独立 CSV 再导。stroke_count用TINYINT UNSIGNED就够常用汉字笔画数不会超过 255codepoint用INT UNSIGNED最大 0x10FFFF 完全装得下radical用VARCHAR(4)并指定二进制排序规则避免不同排序规则下同一个部首比较结果飘。下面 DDL 里保留radical_order因为按传统部首序排和按部首字符码点排是两回事少了这个字段前端看到的“氵”不一定排在它该在的位置。2.2 Unicode 码点、UTF8MB4 与繁简字段的落位码点建议存十进制整数不存U4E00这种字符串。U9F98对应40856U20000对应131072扩展 B 区的字符一旦用字符串比较很容易在排序和范围查询上吃亏。字符列用CHAR(1)在utf8mb4下可以存一个完整字符包括四字节的扩展区汉字但客户端连接、列字符集、表字符集任何一层掉到utf8mb3生僻字就会变成问号。繁简字段不要在主表里写死“简体”和“繁体”两个值。常见做法是主表只放字符和码点简繁关系进hanzi_variantrelation_type标清one_to_one、simp_to_many、trad_to_many、variant。比如“发”对应“發”和“髮”这是simp_to_many“后”对应“後”和“后”本身关系又不一样。业务查询时先拿候选再交给词表或分词消歧不要幻想一条UPDATE ... REPLACE能解决所有简繁转换。字符集统一用utf8mb4排序规则在 MySQL 8.0 可以用utf8mb4_0900_ai_ciMySQL 5.7 用utf8mb4_unicode_ci更稳。排序规则影响比较和排序不影响存储按笔画排序时最终还是要靠stroke_count、radical_order、codepoint这三个键不能指望ORDER BY ch给出字典序。2.3 建库建表一份可以直接跑的 DDLCREATE DATABASE IF NOT EXISTS hanzi_dict DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE hanzi_dict; CREATE TABLE hanzi_char ( codepoint INT UNSIGNED NOT NULL COMMENT Unicode码点如U4E00存19968, ch CHAR(1) NOT NULL COMMENT 字符本身, block_name VARCHAR(32) DEFAULT NULL COMMENT 所属Unicode区块, is_common TINYINT UNSIGNED NOT NULL DEFAULT 0 COMMENT 是否常用字, PRIMARY KEY (codepoint), UNIQUE KEY uk_ch (ch) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci; CREATE TABLE hanzi_attr ( codepoint INT UNSIGNED NOT NULL, stroke_count TINYINT UNSIGNED NOT NULL COMMENT 规范笔画数, radical VARCHAR(4) COLLATE utf8mb4_bin DEFAULT NULL COMMENT 部首字符, radical_order SMALLINT UNSIGNED DEFAULT NULL COMMENT 传统部首序号没有就置NULL, radical_stroke TINYINT UNSIGNED DEFAULT NULL COMMENT 部首笔画, structure VARCHAR(8) DEFAULT NULL COMMENT 左右/上下/包围等, pinyin VARCHAR(64) DEFAULT NULL COMMENT 多音字用逗号分隔检索另拆表, attr_source VARCHAR(16) DEFAULT NULL COMMENT 笔画口径来源标记, PRIMARY KEY (codepoint), KEY idx_stroke (stroke_count, radical_order, codepoint), CONSTRAINT fk_attr_char FOREIGN KEY (codepoint) REFERENCES hanzi_char (codepoint) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci; CREATE TABLE hanzi_variant ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, simp_codepoint INT UNSIGNED NOT NULL, trad_codepoint INT UNSIGNED NOT NULL, relation_type ENUM(one_to_one,simp_to_many,trad_to_many,variant) NOT NULL DEFAULT one_to_one, note VARCHAR(128) DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_pair (simp_codepoint, trad_codepoint), KEY idx_simp (simp_codepoint), KEY idx_trad (trad_codepoint) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;这段 DDL 的逻辑是hanzi_char先落字符和码点hanzi_attr通过外键挂属性hanzi_variant单独存映射。导入顺序也必须是先hanzi_char再hanzi_attr最后hanzi_variant否则外键会拦。参数上radical指定了utf8mb4_bin是为了让部首比较按字节稳定idx_stroke把stroke_count、radical_order、codepoint串起来后面做按笔画分页时可以直接走索引。pinyin没有拆表适合展示如果要做拼音首字母检索建议另建hanzi_pinyin不要在这个字段上LIKE %xx%。提示MySQL 5.7 没有utf8mb4_0900_ai_ci建库时用utf8mb4_unicode_ciMySQL 8.0 可以按需替换但同一套表里不要混用排序规则否则 JOIN 时可能出现隐式转换。2.4 导入前的字段映射与数据清洗口径资源包里的 CSV 列名不一定和你的表一致常见列有“码点、字符、笔画数、部首、部首笔画、结构、拼音、繁体字”。导入前先做一轮清洗去掉 BOM、统一U前缀、校验字符和码点是否对得上、跳过代理区码点、空笔画不要默认填 0而是置NULL并在查询里过滤。下面这段 Python 只做码点解析和单字符校验适合在入库前跑一遍。import csv import re def parse_cp(raw): s str(raw).strip().upper() s re.sub(r^(U\|0X), , s) s s.replace( , ) if not s: raise ValueError(empty codepoint) cp int(s, 16) if cp 0x10FFFF or 0xD800 cp 0xDFFF: raise ValueError(finvalid codepoint: {raw}) return cp def clean_row(row): cp parse_cp(row[codepoint]) ch row[char].strip() if len(ch) ! 1: raise ValueError(fchar not single: {ch!r}) if ord(ch) ! cp: raise ValueError(fcodepoint mismatch: {ch} {cp}) stroke row.get(stroke_count, ).strip() return { codepoint: cp, ch: ch, stroke_count: int(stroke) if stroke else None, radical: row.get(radical, ).strip() or None, structure: row.get(structure, ).strip() or None, pinyin: row.get(pinyin, ).strip() or None, } with open(hanzi.csv, encodingutf-8-sig, newline) as f: for row in csv.DictReader(f): item clean_row(row) # 这里接临时表或批量写入先不直接进正式表这段代码的关键点有三个utf-8-sig处理 BOM0xD800-0xDFFF是代理区不能单独成字ord(ch) ! cp能挡掉码点和字符错位的数据。参数上stroke_count为空时返回None不要填 0后面对笔画排序时加WHERE stroke_count IS NOT NULL否则空值会排在最前面。实际导入前我还会把清洗失败的行单独输出别让一条脏数据把整批导入卡住。3. 把字库跑起来从 CSV 导入到按笔画查询的完整链路3.1 LOAD DATA 导入与字符集参数导入阶段最容易被忽略的是连接字符集和local_infile。先确认服务端和客户端都认utf8mb4再执行LOAD DATA LOCAL INFILE。下面以字符主表为例假设 CSV 第一列是U4E00这种格式第二列是字符本身如果你的资源列顺序不同把cp_hex、ch的位置对调即可。SET NAMES utf8mb4; SHOW VARIABLES LIKE local_infile; LOAD DATA LOCAL INFILE /tmp/hanzi_char.csv INTO TABLE hanzi_char CHARACTER SET utf8mb4 FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY LINES TERMINATED BY \n IGNORE 1 LINES (cp_hex, ch, block_name, is_common) SET codepoint CONV(SUBSTRING(UPPER(TRIM(cp_hex)), 3), 16, 10), ch ch;这段 SQL 的逻辑是先把原始列读进用户变量再在SET里把U4E00去掉前两位转成十进制。CHARACTER SET utf8mb4必须写否则客户端默认字符集可能把四字节字符截断OPTIONALLY ENCLOSED BY 处理字段里带逗号的情况IGNORE 1 LINES跳过表头没有表头就删掉。LOCAL需要客户端开启local_infile生产库上一般由 DBA 控制导入完记得关掉。属性表和映射表同理只是列不同LOAD DATA LOCAL INFILE /tmp/hanzi_attr.csv INTO TABLE hanzi_attr CHARACTER SET utf8mb4 FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY LINES TERMINATED BY \n IGNORE 1 LINES (cp_hex, stroke_count, radical, radical_order, radical_stroke, structure, pinyin, attr_source) SET codepoint CONV(SUBSTRING(UPPER(TRIM(cp_hex)), 3), 16, 10);参数上stroke_count直接进TINYINT UNSIGNED导入前确认没有小数和空字符串radical_order没有就填NULL不要填 0因为 0 会参与排序。大文件不要一条事务包到底按 5 万到 10 万行分批提交失败时只回滚当前批排查成本低很多。导入完成后先跑SELECT COUNT(*)和 CSV 行数对账再看SHOW WARNINGS很多“少了几行”的问题在 warning 里已经写明了。3.2 用生成列/索引解决“按笔画排序部首筛选”按笔画排序不是简单一句ORDER BY stroke_count。同笔画的字还要按部首序最后用码点兜底否则分页时顺序会飘。下面这条查询走idx_stroke先筛笔画区间再按部首序号和码点排。SELECT c.ch, c.codepoint, a.stroke_count, a.radical FROM hanzi_char c JOIN hanzi_attr a ON a.codepoint c.codepoint WHERE a.stroke_count BETWEEN 8 AND 12 ORDER BY a.stroke_count, a.radical_order, a.codepoint LIMIT 50;参数说明BETWEEN 8 AND 12是业务筛选条件实际接口里由前端传radical_order为NULL的字会排在前面如果不想让它们干扰加AND a.radical_order IS NOT NULL。深分页不要用LIMIT 100000, 50改成游标SELECT c.ch, c.codepoint, a.stroke_count, a.radical_order FROM hanzi_char c JOIN hanzi_attr a ON a.codepoint c.codepoint WHERE a.stroke_count 8 AND (a.stroke_count, a.radical_order, a.codepoint) (8, 120, 27700) ORDER BY a.stroke_count, a.radical_order, a.codepoint LIMIT 50;这里的(8, 120, 27700)是上一页最后一条的排序键行构造器比较能保证不重不漏。前提是radical_order和codepoint都不为NULL如果资源里没有部首序号就把radical_order换成radical但记得给radical用二进制排序规则否则大小写和重音规则会让游标比较出现意外。3.3 简繁映射查询同码点、异体字与一对多简繁查询的核心是“先拿候选再做消歧”。下面这条 SQL 查“发”对应的繁体候选结果会返回“發”和“髮”relation_type标成simp_to_many。SELECT s.ch AS simp_ch, t.ch AS trad_ch, v.relation_type FROM hanzi_variant v JOIN hanzi_char s ON s.codepoint v.simp_codepoint JOIN hanzi_char t ON t.codepoint v.trad_codepoint WHERE s.ch 发 ORDER BY v.relation_type, t.codepoint;反向查询把WHERE s.ch 发换成WHERE t.ch 後就能看到“後”对应“后”。参数上relation_type不是装饰字段simp_to_many表示一个简体对多个繁体业务层不能只取第一行variant表示异体字关系适合做字形归一不适合直接当简繁转换。实际接口里我一般返回候选数组再让分词或词表决定用哪个比如“头发”走“髮”“发现”走“發”单靠字库本身消不了这个歧义。3.4 验证数据完整性码点覆盖、笔画分布与抽样对拍导入完成后别急着接业务先跑三组校验。第一组看主表码点和字符是否一致第二组看笔画分布有没有异常断层第三组抽样扩展区字符确认四字节存储没被截断。-- 1) 字符与码点是否一致BMP范围先跑扩展区用程序复核 SELECT COUNT(*) AS bad_cp FROM hanzi_char WHERE ORD(ch) codepoint; -- 2) 笔画分布正常应该集中在 5-15 画0 画和 30 画以上要人工看 SELECT stroke_count, COUNT(*) AS cnt FROM hanzi_attr GROUP BY stroke_count ORDER BY stroke_count; -- 3) 缺失属性的字符 SELECT c.codepoint, HEX(c.ch) AS hex_ch FROM hanzi_char c LEFT JOIN hanzi_attr a ON a.codepoint c.codepoint WHERE a.codepoint IS NULL LIMIT 20; -- 4) 抽样扩展区LENGTH4 表示四字节CHAR_LENGTH1 表示一个字符 SELECT codepoint, ch, HEX(ch) AS hex_ch, CHAR_LENGTH(ch) AS char_len, LENGTH(ch) AS byte_len FROM hanzi_char WHERE codepoint IN (0x4E00, 0x9F98, 0x20000);ORD(ch)对基本区和部分扩展区能返回码点但跨版本行为不完全一致扩展区建议用程序读出来再比。第二组查询里如果某个笔画数突然为 0先查是不是空值被转成了 0第三组缺失属性如果集中在扩展区说明属性表没覆盖全不一定是导入失败。第四组里LENGTH(ch)4、CHAR_LENGTH(ch)1是正常四字节字符如果LENGTH只有 3说明连接或列字符集掉到了utf8mb3。4. 避坑与排查简繁字库里最容易翻车的五件事4.1 现象生僻字显示问号现象查询“龘”返回???或者前端拿到的是替换字符。原因连接字符集、列字符集、客户端终端任意一层不是utf8mb4。utf8在 MySQL 里是utf8mb3最多三字节存不下扩展区汉字。解决先看全局变量和列定义再用HEX(ch)判断存储本身有没有坏。SHOW VARIABLES LIKE character_set%; SHOW FULL COLUMNS FROM hanzi_char; SELECT ch, HEX(ch) AS hex_ch, LENGTH(ch) AS byte_len FROM hanzi_char WHERE codepoint 0x9F98;如果HEX(ch)是E9BE98这类三字节说明存进去时已经被截断如果是四字节F0A0...问题在客户端展示。建库、建表、连接三处都统一utf8mb4导入前SET NAMES utf8mb4。已有表可以用ALTER TABLE hanzi_char CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;但大表会锁先在从库或低峰期做。4.2 现象按笔画排序结果不对现象同是 8 画“阿”和另一个 8 画字顺序和字典不一致分页第二页还重复。原因笔画口径不统一。资源里可能混了简体笔画、繁体笔画、姓名学笔画radical_order为空时又按radical字符码点排传统部首序自然对不上排序键只写stroke_count没有唯一兜底。解决给属性表加attr_source标记口径同一业务只认一套没有部首序号就补补不了就明确按码点排排序键固定为stroke_count, radical_order, codepoint。SELECT c.ch, a.stroke_count, a.radical_order, a.attr_source FROM hanzi_char c JOIN hanzi_attr a ON a.codepoint c.codepoint WHERE a.stroke_count 8 ORDER BY a.stroke_count, a.radical_order, a.codepoint LIMIT 100;如果radical_order大量为NULL先别急着上传统部首序把NULL单独分组看数量。参数上attr_source建议用短字符串比如standard、trad、name不要用中文长句索引和比较都轻。4.3 现象简繁转换把“发”转错现象“头发”被转成“头發”“发现”被转成“发现”没问题但“理发”又错了。原因把简繁映射当成一一对应hanzi_variant只存了一行或者业务代码JOIN后取了LIMIT 1。解决映射表保留多行查询返回候选业务层用词表或分词消歧不要写UPDATE ... REPLACE(ch, 发, 發)这种全表替换。SELECT s.ch AS simp_ch, t.ch AS trad_ch, v.relation_type FROM hanzi_variant v JOIN hanzi_char s ON s.codepoint v.simp_codepoint JOIN hanzi_char t ON t.codepoint v.trad_codepoint WHERE s.ch 发;返回两行是正常的relation_type为simp_to_many时接口就应该返回数组。参数上note可以记“发/髮”的语义提示但不要指望它自动消歧真要做高质量转换得配词表字库只负责给候选。4.4 现象导入后行数少了/多了现象CSV 有 2 万行导入后COUNT(*)少几百或者多了重复行。原因字段内有逗号没加引号、BOM 导致首列码点解析失败、重复码点触发主键冲突、LOAD DATA的 warning 被忽略。解决先导临时表去掉主键和唯一键导完对账再合并进正式表。CREATE TABLE hanzi_char_stg LIKE hanzi_char; ALTER TABLE hanzi_char_stg DROP PRIMARY KEY, DROP INDEX uk_ch; LOAD DATA LOCAL INFILE /tmp/hanzi_char.csv INTO TABLE hanzi_char_stg CHARACTER SET utf8mb4 FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY LINES TERMINATED BY \n IGNORE 1 LINES (cp_hex, ch, block_name, is_common) SET codepoint CONV(SUBSTRING(UPPER(TRIM(cp_hex)), 3), 16, 10); SELECT COUNT(*) AS stg_cnt FROM hanzi_char_stg; SHOW WARNINGS; INSERT INTO hanzi_char (codepoint, ch, block_name, is_common) SELECT codepoint, ch, block_name, is_common FROM hanzi_char_stg ON DUPLICATE KEY UPDATE ch VALUES(ch), block_name VALUES(block_name), is_common VALUES(is_common);临时表去掉唯一键是为了先看清重复数据不要一上来就让主键把行挡掉。ON DUPLICATE KEY UPDATE适合修正属性不适合盲目覆盖合并前先GROUP BY codepoint HAVING COUNT(*)1看重复来源。4.5 现象查询命中不了扩展区汉字现象表里明明有“”按字符查不到按码点范围也查不出。原因列还是utf8mb3或者码点存成了字符串U20000又或者客户端把四字节字符拆成了代理对。解决列统一utf8mb4码点存INT UNSIGNED查询用十进制或0x字面量范围查扩展 B 用0x20000到0x2A6DF。SELECT codepoint, ch, HEX(ch) AS hex_ch FROM hanzi_char WHERE codepoint BETWEEN 0x20000 AND 0x2A6DF LIMIT 10;如果这条查不到先确认导入时有没有把U20000正确转成131072如果查到了但显示问号回到 4.1 查连接字符集。参数上扩展 B 的排序不要依赖默认排序规则直接按codepoint排稳定且可复现。5. 进阶用法把笔画库接进搜索排序与校验的四个细节5.1 笔画排序与分页稳定键按笔画排序接 API 时我习惯把(stroke_count, radical_order, codepoint)作为稳定排序键前端只传上一页最后一条的三个值。这样即使中间补录了新字也不会出现第二页重复。LIMIT OFFSET在几万行以内还能忍到了几十万行就开始拖游标分页的 SQL 在第 3 章已经给过关键是索引要盖住这三个字段别让优化器回表排序。5.2 用码点区间做生僻字兜底输入校验不要用\u4e00-\u9fa5这种正则它漏掉扩展 A 和扩展 B。下面这张表是我常用的兜底区间命中不代表一定是汉字但不在区间里基本可以先拦掉。区间名称用途0x4E00-0x9FFF基本区常用汉字主覆盖0x3400-0x4DBF扩展 A生僻字补充0x20000-0x2A6DF扩展 B四字节生僻字0x2F800-0x2FA1F兼容补充字形兼容谨慎入库SQL 里可以写成CASE WHEN codepoint BETWEEN 0x4E00 AND 0x9FFF THEN basic ...业务层拿到区间标记后再决定是否走字库校验。注意兼容区字符可能有重复字形做去重时以码点为准不要以ch为准。5.3 一个可复用的校验 SQL 与维护习惯每次更新字库前我会先跑一遍总账主表多少行、属性表多少行、缺属性多少、映射断链多少。下面这条 SQL 直接返回四个数接监控也方便。SELECT (SELECT COUNT(*) FROM hanzi_char) AS char_cnt, (SELECT COUNT(*) FROM hanzi_attr) AS attr_cnt, (SELECT COUNT(*) FROM hanzi_char c LEFT JOIN hanzi_attr a ON a.codepoint c.codepoint WHERE a.codepoint IS NULL) AS missing_attr, (SELECT COUNT(*) FROM hanzi_variant v LEFT JOIN hanzi_char s ON s.codepoint v.simp_codepoint LEFT JOIN hanzi_char t ON t.codepoint v.trad_codepoint WHERE s.codepoint IS NULL OR t.codepoint IS NULL) AS broken_variant;这四个数里missing_attr和broken_variant只要不为 0就先别接线上排序。维护上每次导入前备份正式表导入后用CHECKSUM TABLE或行数对账资源包升级时先比对新旧码点集合不要直接REPLACE INTO全表覆盖。从那以后我每次把字库接进业务前都会先跑一遍码点覆盖和笔画分布对比再让排序字段走完整索引希望帮到你。本文还有配套的精品资源点击获取

简繁汉字库MySQL建表、导入与按笔画排序实践

相关推荐

分布式系统熔断限流实战：Sentinel核心原理与应用

零基础搞定CATIA二次开发：CAA、RADE与VS环境搭建全攻略

32位Office与64位ACE引擎安装冲突：根因分析与MSI修改解决方案

更多资讯

拼多多反爬虫策略解析与逆向实战

电商平台内容风控技术解析与实战优化

YOLO高并发推理性能优化实战与Java集成方案

Flink Task Slot深度解析：资源调度的神经中枢与细粒度管理实践

JavaScript函数流水线：高效编程的核心技术

SQL注入靶场实战：从基础到进阶技术解析

今日更新

Agent-Reach：打通大模型触达外部系统的最后一公里

深度学习图像隐写分析实战：从CNN原理到毕设源码全解析

AI赋能知识产权供需匹配：专利评估、需求挖掘与多路召回工程实践

本周精选

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

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

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

本月热门

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

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

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

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