Python成语接龙实战：从内存方案到SQLite/MySQL数据库重构-北京尧图网络

如果你去搜“python 成语接龙”十有八九会看到同一个套路一个列表装成语input()接玩家输入endswith和startswith比一下首尾字循环就结束了。我以前也这么干直到我想把词库从几百条扩到几万条、想给游戏加对局记录和战绩统计才发现那个 list 方案根本撑不住。后来我把整个项目重构成“成语接龙连接数据库”的形态数据层用数据库管理程序只负责游戏逻辑整套代码一下变得干净又抗造。这篇文章就讲讲我在这个项目里的完整思路为什么非要用数据库、数据库怎么选、成语词库怎么入库、接龙逻辑怎么和 SQL 配合以及我从 SQLite 换到 MySQL 过程中踩过的一堆坑。适合想用 Python 做完整小项目、又不太清楚“连接数据库”到底在连什么的同学直接参考。1. 先讲动机一个接龙游戏为什么非要拽上数据库很多人看到“成语接龙”连数据库第一反应是小题大做一个list加一个set不就全搞定确实如果你只是本地自己玩两局内存方案完全够用。但只要你把项目往前推一步——词库上万、游戏要存档、要支持多人对战——内存方案就会暴露出明显短板。1.1 内存方案撑不住的三个场景第一个场景是词库加载。词库上了万条之后程序每次启动都要重新加载、去重、构造数据结构初始化逻辑越来越重。更麻烦的是成语数据本身是有规则的单纯放在 list 里没办法做复杂查询比如“所有以‘风’字开头、并且在词库里没有被使用过的成语”这种需求用内存做也能写但代码会越来越绕。第二个场景是持久化。内存方案里“用过哪些词”是存在set里的程序一退出全部归零。你可能觉得无所谓但一旦对局到一半想关掉、或者服务端要记录每一局的过程这点就很致命。第三个场景是数据维护。没有数据库时想加一条成语就得改代码、重启服务。有了数据库以后成语变成了一条记录直接往表里插和游戏逻辑完全解耦。1.2 从单人游戏到多人在线的能力缺口如果只是单机练习上述场景忍忍也就过去了。但做多人在线成语接龙时问题会直接放大多个玩家同时操作怎么保证“同一个成语不会被两个人同时用掉”内存方案里set的增删改查在单进程内没有问题但一旦拆成客户端/服务端架构数据共享必须落到一个公共存储层数据库这时候不是“可选项”而是“必选项”。数据库的事务和锁能帮你处理并发冲突。一个成语在 A 玩家刚说完、B 玩家还没刷新的时候数据库的唯一约束和事务隔离能保证这条数据只被记录一次。这些语义如果在内存里自己实现等于重写一遍数据库。1.3 数据库帮你解决的四个实际问题我把这个项目里数据库实打实解决的四个问题列一下快速查询按首字/末字匹配成语走索引之后万级词库也是毫秒级返回。防重复表结构加唯一索引从源头避免同一词条被插两次。持久化对局记录、玩家战绩、用过的词程序重启也不丢。多人共享多个客户端连同一份词库数据而不是各自加载一份自己的 list。说白了数据库在这里干的事就是把你原来写在代码里的那些“全局变量”和“临时集合”换成了受约束的、可持久化的、支持并发访问的存储层。想清楚这一点后面所有设计都顺了。2. 环境准备与数据库选型SQLite先跑通MySQL再上强度数据库不是只有一种选型要跟着项目阶段走。我的建议是第一步无脑选 SQLite跑通整个流程等你真要做在线服务了再换成 MySQL。理由在下面展开。2.1 SQLite和MySQL的定位差异先看一张我整理过的对比表维度SQLiteMySQL部署成本零配置Python 内置模块需要安装服务端数据存储单个文件拷走即备份服务端文件需导出导入并发能力弱写操作会锁库强支持大量并发连接适用场景单机、学习、原型验证在线服务、多用户对战Python 驱动sqlite3无需安装pymysql或mysql-connector-python学习成本低略高但 SQL 核心一致SQLite 是嵌入式数据库它不是一个服务而是你程序直接操作的一个文件。MySQL 是标准的客户端/服务端架构你的程序作为客户端连过去发 SQL。两者的 SQL 语法 95% 兼容所以先用 SQLite 把逻辑跑通后面切 MySQL 的成本很低。2.2 Python环境准备别在这卡壳Python 版本建议 3.8 以上。装好后命令行验证一下python --version如果电脑里有多个 Python 版本最好给这个项目建虚拟环境避免依赖装乱python -m venv venv venv/Scripts/activate # Windows # 或者 source venv/bin/activate # macOS / Linux如果直接上 MySQL再装一个驱动pip install pymysql我用的开发工具是 VS CodePython 扩展装上选择解释器时指向刚才创建的 venv 就行。这块不用追求复杂能跑python xxx.py就够了。2.3 连接数据库的标准动作不管你用 SQLite 还是 MySQL“连接数据库”的本质是完成五个动作建立连接、创建游标、执行 SQL、提交事务、关闭连接。先看 SQLiteimport sqlite3 conn sqlite3.connect(idioms.db) cur conn.cursor() cur.execute(SELECT COUNT(*) FROM idioms) print(cur.fetchone()[0]) conn.close()再看 MySQL 用 pymysql 连import pymysql conn pymysql.connect( host127.0.0.1, port3306, userroot, passwordyour_password, databaseidiom_game, charsetutf8mb4, connect_timeout5, ) cur conn.cursor() cur.execute(SELECT COUNT(*) FROM idioms) print(cur.fetchone()[0]) conn.close()注意MySQL 连接参数里charsetutf8mb4不是可选项是必选项不然后面存生僻字和特殊符号会出问题。这个坑我在后面第 6 节专门展开。为什么每个连接都要 close数据库服务端能同时维护的连接数是有限的你一个程序里反复建立连接但不关闭连接数很快被打满后面再连就会报too many connections。所以代码规范上连接用完一定要关。3. 成语词库从零整理一份能入库的成语数据数据库连上了下一步得有数据。成语接龙的核心是词库词库质量直接决定游戏体验。我在这个项目里最花时间的不是写代码是整理词库。3.1 词库来源与统一格式成语词库常见来源有三个GitHub 上的开源词库仓库、在线成语词典抓取、自己手里的文本文件整理。不管哪条路最终都要转成统一的 JSON 或 CSV 格式进去。我用的格式大概长这样[ {word: 一目了然, pinyin: yī mù liǎo rán, meaning: 一眼就看得很清楚。}, {word: 然糠自照, pinyin: rán kāng zì zhào, meaning: 比喻勤奋学习。} ]注意拼音和释义不是必须的但建议留着。释义能给玩家更好的反馈拼音则是做“谐音接龙”的基础。没有拼音的词库后面想加同音字模式就得回头重弄。3.2 表结构设计首字末字单独成列的价值很多新手建表只存一个word字段等写查询的时候才发现难受。接龙规则要求“当前成语的末字下一个成语的首字”如果只存整体成语每次匹配都得在 SQL 里用LIKE x%或者把word[0]和word[-1]放进查询条件。问题是LIKE x%对索引不友好子串匹配更是全表扫描。所以我建表时把首字和末字直接拆出来单独成列CREATE TABLE IF NOT EXISTS idioms ( id INTEGER PRIMARY KEY AUTOINCREMENT, word TEXT NOT NULL UNIQUE, first_char TEXT NOT NULL, last_char TEXT NOT NULL, pinyin TEXT DEFAULT , first_pinyin TEXT DEFAULT , last_pinyin TEXT DEFAULT , meaning TEXT DEFAULT , level INTEGER DEFAULT 0 );first_char和last_char不是冗余是专门为查询设计的索引列。查询语句从“匹配整个词的模糊查询”变成了“匹配首字的等值查询”性能完全不是一个量级。3.3 清洗与批量导入词库来源杂脏数据也多。我的清洗规则有三条去掉空白字符、过滤包含非汉字字符的词条、控制词长范围成语不全是四字像“破天荒”“杯酒释兵权”也有但太长的词条如果不是词库刻意收录尽量过滤掉。批量导入用executemany一次插一批比逐条execute快一个数量级。同时配合INSERT OR IGNORESQLite 语法和唯一索引重复导入同一个词库文件时重复词会被自动忽略不会越导越多。这里有一个经验第一次建索引的时间比插入数据的时间还长但为了后面查询快这个索引必须建。直接在表创建脚本里写上索引语句一次性搞定。3.4 词库规模怎么定2000~5000 条适合本地练手词库质量容易控制。1 万~3 万条适合做成在线服务覆盖大部分常见接龙场景。5 万条以上需要处理“词库存了很多游戏玩家根本不认识的生僻词”的问题。词库里十几万条生僻词不一定好玩玩家接完一个“魑魅魍魉”下一步谁接得上所以我在表里加了level字段用来标记常用程度。做游戏时可以先从level比较高的词里选难度曲线就出来了。这个字段在你只有词库文本的时候可以先都填 0后面想精细化再单独更新。4. 核心逻辑与SQL查询接龙不是简单的startswith词库准备好了接下来是最核心的部分接龙逻辑。表面上就是“上一个词的末字和下一个词的首字一致”但真正落到代码里有三重校验和不少边界情况。4.1 接龙规则的三重校验一个玩家输入的成语要合法必须同时满足三个条件第一这个词确实在词库里存在第二这个词没有被使用过第三这个词的首字必须等于当前成语的末字。注意校验顺序很关键。先查词库是否存在再查是否首字匹配最后才查是否重复这样给出的报错信息更准确。如果先查重复一个新词因为之前被用到过就报“重复”会误导玩家。4.2 候选词查询SQL写法和参数化细节查询候选词是游戏里最频繁的 SQL。我的实现是这样的import sqlite3 from contextlib import closing DB_PATH idioms.db def get_conn(): conn sqlite3.connect(DB_PATH) conn.row_factory sqlite3.Row return conn def get_candidates(last_char, used_words, limit5): used_list list(used_words) with closing(get_conn()) as conn: if used_list: placeholders ,.join(? * len(used_list)) sql f SELECT word, meaning FROM idioms WHERE first_char ? AND word NOT IN ({placeholders}) ORDER BY RANDOM() LIMIT ? rows conn.execute(sql, (last_char, *used_list, limit)).fetchall() else: sql SELECT word, meaning FROM idioms WHERE first_char ? ORDER BY RANDOM() LIMIT ? rows conn.execute(sql, (last_char, limit)).fetchall() return [dict(r) for r in rows]这段代码有两个细节一是NOT IN后面的占位符是动态生成的用?配合参数传入不要直接拼接字符串防止注入风险本地项目也一样要养成习惯二是ORDER BY RANDOM()让电脑每次挑的成语不完全一样增加变化。如果used_list特别大比如一局游戏已经用了 100 多个词NOT IN的性能会下降。这时可以换一种写法用LEFT JOIN排除用过的词。但一般接龙一局到不了那么长NOT IN足够用了。4.3 同音字与多音字的进阶玩法严格字接是“末字首字”比如“一心一意”之后接“意气风发”。但很多人玩接龙时喜欢放水允许谐音只要末字的拼音和首字的拼音相同忽略声调就算接上。要做谐音接龙表里的first_pinyin和last_pinyin字段就派上用场了。查询时把first_char ?改成first_pinyin ?就行。但谐音模式有两个前提要处理一是多音字比如“落”有luò和là两个读音词库存一个读音会导致部分本该能接的词被漏掉二是轻声比如“了”读le接龙时要不要算进去。我的建议是不要在一开始就上谐音模式。先把严格字接跑通后面再扩展。如果要做谐音就先在清洗阶段统一读音把多音字选一个最常用的读法存进去。这样会牺牲一部分准确性但数据模型简单很多。4.4 电脑策略和死局判断人机对战时电脑怎么选词决定了游戏难度。最简单的是随机选一个合法词玩家体验也还行。想提升难度可以做一点贪心策略在每个候选词后面再查一次“以这个词末字开头的可用词还有多少”优先选候选项最少的成语让玩家更难接下去。这其实就是博弈里“切断对手退路”的思路。死局判断很简单查询当前末字开头的可用词数量如果为 0游戏结束。不要靠“玩家说一句我们试一句”来推断那个不可靠直接一次COUNT查询最准确。5. 完整实现从建库到跑通一局人机接龙前面几节把核心设计讲完了这一节给出完整的、可以直接抄走跑通的代码。我用的是 SQLite因为零配置任何人拿到代码装上 Python 就能跑。5.1 项目文件结构idiom_game/ ├── idioms.json # 原始词库 ├── init_db.py # 建库导入 ├── db.py # 数据库操作封装 ├── game.py # 接龙核心逻辑 └── main.py # 命令行交互入口5.2 init_db.py建表与导入import json import sqlite3 def load_data(pathidioms.json): with open(path, r, encodingutf-8) as f: data json.load(f) cleaned [] for item in data: word item.get(word, ).strip() if not word: continue # 只保留纯汉字的词条去掉包含数字、字母、空格的脏数据 if not all(\u4e00 ch \u9fff for ch in word): continue if not (2 len(word) 8): continue cleaned.append({ word: word, first_char: word[0], last_char: word[-1], pinyin: item.get(pinyin, ), meaning: item.get(meaning, ), }) return cleaned def init_db(db_pathidioms.db, data_pathidioms.json): conn sqlite3.connect(db_path) cur conn.cursor() cur.execute( CREATE TABLE IF NOT EXISTS idioms ( id INTEGER PRIMARY KEY AUTOINCREMENT, word TEXT NOT NULL UNIQUE, first_char TEXT NOT NULL, last_char TEXT NOT NULL, pinyin TEXT DEFAULT , first_pinyin TEXT DEFAULT , last_pinyin TEXT DEFAULT , meaning TEXT DEFAULT , level INTEGER DEFAULT 0 ) ) cur.execute(CREATE INDEX IF NOT EXISTS idx_first_char ON idioms (first_char)) cur.execute(CREATE INDEX IF NOT EXISTS idx_last_char ON idioms (last_char)) data load_data(data_path) rows [] for item in data: pinyin_parts item[pinyin].split() rows.append(( item[word], item[first_char], item[last_char], item[pinyin], pinyin_parts[0] if pinyin_parts else , pinyin_parts[-1] if pinyin_parts else , item[meaning], )) cur.executemany( INSERT OR IGNORE INTO idioms (word, first_char, last_char, pinyin, first_pinyin, last_pinyin, meaning) VALUES (?, ?, ?, ?, ?, ?, ?) , rows, ) conn.commit() count cur.execute(SELECT COUNT(*) FROM idioms).fetchone()[0] print(f导入完成当前词库共 {count} 条) conn.close() if __name__ __main__: init_db()INSERT OR IGNORE配合 UNIQUE 约束是防重复导入的关键。你只要不改idioms.json重复跑这个脚本不会把词库翻倍。5.3 db.py数据访问层import sqlite3 from contextlib import closing DB_PATH idioms.db def get_conn(): conn sqlite3.connect(DB_PATH) conn.row_factory sqlite3.Row return conn def word_exists(word): with closing(get_conn()) as conn: row conn.execute( SELECT word, meaning FROM idioms WHERE word ?, (word,), ).fetchone() return dict(row) if row else None def get_candidates(last_char, used_words, limit5): used_list list(used_words) with closing(get_conn()) as conn: if used_list: placeholders ,.join(? * len(used_list)) sql f SELECT word, meaning FROM idioms WHERE first_char ? AND word NOT IN ({placeholders}) ORDER BY RANDOM() LIMIT ? rows conn.execute( sql, (last_char, *used_list, limit) ).fetchall() else: sql SELECT word, meaning FROM idioms WHERE first_char ? ORDER BY RANDOM() LIMIT ? rows conn.execute(sql, (last_char, limit)).fetchall() return [dict(r) for r in rows]这里每次查询都新建连接、用完就关。有人会觉得频繁开关连接开销大但对于 SQLite 这种嵌入式数据库来说这个操作很轻量完全没问题。以后如果换 MySQL单机并发不大同样可以直接用短连接省去管理连接池的复杂度。5.4 game.py游戏核心逻辑from db import word_exists, get_candidates class IdiomGame: def __init__(self): self.used set() self.current None def human_play(self, word): if not word: return False, 不能输入空内容 if word in self.used: return False, 这个词已经用过了 if self.current and word[0] ! self.current[-1]: return False, f首字必须是{self.current[-1]} record word_exists(word) if not record: return False, 词库里没有这个词 self.used.add(word) self.current word return True, f正确当前成语{word} def computer_play(self): if not self.current: return None candidates get_candidates(self.current[-1], self.used, limit5) if not candidates: return None # 这里简单取随机候选中的第一个作为进阶优化可以改成 # “选择后续候选数最少的成语”来给玩家制造难度 chosen candidates[0] self.used.add(chosen[word]) self.current chosen[word] return chosen def check_game_over(self): if not self.current: return False candidates get_candidates(self.current[-1], self.used, limit1) return len(candidates) 0几个边界情况在human_play里都处理了输入为空、重复词、首字匹配、词库存在。校验顺序我特意把重复词放在首字匹配前面因为“这个词已经用过了”比“首字不对”更能说明问题玩家一看就懂。5.5 main.py交互入口from game import IdiomGame def main(): game IdiomGame() print(欢迎来到成语接龙) start_word input(请给出第一个成语).strip() ok, msg game.human_play(start_word) if not ok: print(开局失败, msg) return while True: comp game.computer_play() if comp is None: print(电脑接不上了你赢了) break print(f电脑接龙{comp[word]}) if comp[meaning]: print(f释义{comp[meaning]}) if game.check_game_over(): print(没有可用成语了游戏结束。) break word input(轮到你了请接龙).strip() ok, msg game.human_play(word) if not ok: print(输入不合法, msg) continue if game.check_game_over(): print(你已经把路走完了电脑认输) break if __name__ __main__: main()运行效果大概是这样的欢迎来到成语接龙请给出第一个成语一心一意电脑接龙意气风发释义形容精神振奋气概豪迈。轮到你了请接龙发人深省输入不合法词库里没有这个词轮到你了请接龙发扬光大电脑接龙大器晚成释义比喻成名或取得成就比较晚。 ……如果玩家一直输入不在词库的词程序不会硬退出而是给提示后让玩家重新输体验更友好。5.6 跑通之后怎么切成MySQL切 MySQL 只需要改db.py里的get_conn()把sqlite3.connect换成pymysql.connect。有两点语法差异需要适配一是 SQLite 的占位符是?MySQL 是%s二是INSERT OR IGNORE在 MySQL 里是INSERT IGNORE。其他地方比如建表 SQL、索引语法基本不用动。这就是当初选 SQLite 跑通的好处切换成本被压到最低。6. 实测中的坑字符集、超时和连接泄漏最后这部分是我实际把项目从 SQLite 迁到 MySQL、并且试图做成一个小型在线服务时踩的坑。每一个都很经典写出来帮大家省排查时间。6.1 字符集和建库参数SQLite 里基本没有字符集概念但 MySQL 有。我最早建库时没指定字符集默认latin1插入“一目了然”直接报错。后来查了资料才搞清楚建库时要显式指定CREATE DATABASE idiom_game CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;连接参数里也要写charsetutf8mb4。utf8mb4和utf8的区别在于utf8在 MySQL 里最多存 3 字节一些生僻字和 emoji 符号存不进去utf8mb4才是正解。凡是遇到“问号”“报错 Illegal mix of collations”先检查字符集。6.2 连接超时与“MySQL server has gone away”这个坑我在测试长连接的时候碰到过。程序启动时建了一个数据库连接存着一直用结果隔了一段时间再查询直接抛MySQL server has gone away。原因是 MySQL 服务端默认的wait_timeout是 8 小时空闲连接会被服务端掐断。不要试图把wait_timeout调成很大那是治标不治本。正确做法是要么每次操作都新建短连接要么用连接池并在获取连接时检查连接是否可用。我建议在项目初期用短连接代码更直观等并发上来了再引入连接池。6.3 连接泄漏的排查连接泄漏是新手最容易犯的错connect之后忘记close。症状是程序跑一段时间后报too many connections重启又恢复正常。排查方法也简单数据库里执行SHOW PROCESSLIST;如果看到大量Sleep状态的连接多半是代码里连接没关。我的处理方式是全程用contextlib.closing包住连接或者写with语句。前面db.py里就是这么干的连接用完自动关闭从根上杜绝这个问题。6.4 重复导入与唯一约束不加唯一约束时反复导入同一份词库文件表里的数据会翻倍。接龙查询本来走索引很快数据翻倍后依然不慢但词库重复会让“这个词是否已使用”的判断出现歧义游戏的公平性就没法保证了。我在word字段上加了 UNIQUE 约束导入时用INSERT OR IGNORE重复数据进不来。如果你中途发现已经有重复数据了可以用分组查询找出重复项清理掉再补上唯一约束。6.5 控制台中文乱码Windows 的 CMD 默认编码不是 UTF-8跑 Python 程序打印中文成语时会乱码。解决方式是在main.py入口处加一行import sys sys.stdout.reconfigure(encodingutf-8)或者在启动程序之前命令行里执行set PYTHONIOENCODINGutf-8。这个坑不是数据库导致的但在我实测时和数据库一起出现容易一起排查浪费时间。最后分享一个我自己做这个项目时总结的习惯先把整个游戏用纯内存写一版规则跑通之后再把数据层换成 SQLite最后真的要上线了再切 MySQL。每一步只改一层踩坑的边界非常清楚。我再多说一个细节成语词库的level字段建议从一开始就留着后面你想做“从易到难”的模式时就不用回头改表结构了。这个项目最好的地方在于麻雀虽小五脏俱全数据库连接、建表、索引、事务、数据清洗、策略逻辑全都能练到做完之后你对“程序怎么和数据打交道”这件事会有很直观的认识。

Python成语接龙实战：从内存方案到SQLite/MySQL数据库重构

相关推荐

从信息化到数据驱动：数字化转型核心概念与落地路径解析

Meta-Gradient强化学习：原理、推导与PyTorch实现指南

半导体设备通信协议解读：SECS/GEM、HSMS与GEM300联调实战

更多资讯

企业知识库问答Agent：RAG+MCP+多模态架构实战指南

基于Python深度学习的GFPGAN图片修复：从源码到实战

GPU推理并发上限计算器：从物理瓶颈到工程落地

单文件AI编码代理：融合GUI操控与MCP协议的自动化利器

AI Agent治理：防止企业数据泄露的四大缺口与落地实践

FPGA定点牛顿-拉夫逊除法器：Verilog手写高吞吐除法实现

今日更新

插件加载失败深度解析：从did not activate到生命周期排查指南

SpringBoot+Vue+MyBatis企业级房屋租赁管理系统源码解析

企业核心数据灾备自动化：用 OpenClaw 备份到本地 + 云端 + 离线存储的 TaoToken 统一通道实践

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

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

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

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

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