Python新手项目：成语接龙+数据库（SQLite/MySQL）实操全解析

前几天有个朋友问我说python语法学了大半一到写项目就不知道从哪下手让我推荐个练手题目。我跟他说你去写个成语接龙再加个“连接数据库”的环节能折腾明白这一套python基础语法、文件操作、sqlite、参数化查询基本就都过了一遍。这朋友半信半疑结果两周后还真给整出来了效果比我预期还好。今天就把这个项目的完整思路和实操过程摊开讲讲。成语接龙这个题材很适合做新手项目它规则简单清晰——你出一个成语我接下联接的时候用你成语的最后一个字开头就行。难点都藏在细节里成语库存哪、怎么判断用户输入的成语是不是真成语、数据库怎么设计、哪天想换个数据库又怎么改。这些问题处理完你对python的理解绝对会上一个台阶。这个项目适合谁适合已经学完python基础语法、想找个小项目练手的人也适合想搞明白sqlite连接和api怎么用的人。而且它麻雀虽小五脏俱全后面盘点简历的时候也能说“我独立完成过一个带持久化存储的小游戏”比写一百道练习题实在得多。1. 项目全貌成语接龙为什么值得连数据库1.1 一个普通小游戏是怎么变成练手项目的单纯写个成语接龙核心逻辑其实很短。用户输入一个成语程序判断“上一个人的尾字是否和你输入成语的首字相同”再判断“你输入的成语是否存在”然后轮到AI接搞定。三个判断写完游戏就能跑了。但只做到这一步你学到的东西有限。程序一关玩过的记录、胜负统计、你用过的成语历史全都没了。每次启动都是白板一块跟没做过一样。这就是我要引入“连接数据库”的原因。数据库在这里解决的问题很实在成语词库的存储和快速查询。几千个成语放在文件里逐行遍历也行但一旦数据量上来索引和查询效率的差距就出来了。数据库能用SQL直接查还天然支持去重、排序、模糊匹配。游戏历史记录。谁跟谁玩了玩了多久最终接了多长链条这些数据存下来之后可以做统计也能在程序下次启动时加载上次的进度。拓展性。今天接龙是控制台版明天想做成网页版、写个排行榜数据层是现成的不用推翻重来。所以这个项目真正的价值不是“成语接龙”这半个游戏而是“python怎么跟数据库打交道”这整套操作。1.2 技术选型SQLite还是MySQL我为什么推荐这条路很多新手一听到“数据库”第一反应是上MySQL装服务、配账号、设端口还没开始写代码就被环境劝退了。我用这个项目跟你说句实在话先把SQLite搞明白再说MySQL的事。SQLite是python标准库自带的一个轻量型数据库不需要单独安装不需要启动服务就是一个文件用sqlite3模块连上就能操作。你甚至可以把整个数据库理解成一个特殊的excel文件只是这个文件能执行SQL句子。我让朋友先跑SQLite是三层考虑第一学习成本低。它把“连接数据库”最核心的东西提炼出来了——连接、建表、增删改查。你不需要处理网络、权限、账号这些跟业务无关的东西。第二业务适配度刚好。成语接龙这个项目的数据量几十万条成语已经是极限了SQLite完全扛得住。第三迁移路径平滑。SQLite里写的SQL语句除了极少数方言差异到MySQL里几乎可以原样跑。连接方式变一下驱动换一下代码主体不用动。如果你确实想一步到位上MySQL也可以。我下面会单独讲怎么切但建议先把SQLite版跑通再切出了问题你才知道是SQL的问题还是连接的问题。对比项SQLiteMySQL是否需要安装服务不需要需要连接方式sqlite3.connect(文件名.db)pymysql.connect(host, user, password...)数据类型类型亲和比较宽松类型严格适用场景单机小项目、工具脚本多用户并发、网络访问学习成本极低中等2. 先把接龙核心逻辑想清楚2.1 成语库从哪来三种方式我推荐你这么做起飞之前先得有个起飞的地方。成语接龙的数据源是整个项目的地基。第一种手工收集。核心成语也就一两千个常用的但你想撑起一局像样的接龙很快就会发现库不够用。电脑接不上来游戏体验直接打折。手工收集适合做数据验证不适合做正式词库。第二种写脚本抓取。网上有很多公开成语词典的语料写个爬虫批量拿下来存成文件。这个方案能锻炼爬虫技能但要注意数据源网站的robots协议和使用条款而且清洗数据本身也是个不小的工程量。建议作为二期工程去玩别一上来就死磕。第三种用现成的开源成语库。这一步是最省力的很多开发者已经整理好了纯文本格式的成语列表比如一行一个成语的idiom.txt或者带拼音注解的JSON文件。直接下载到本地用python读进来塞进SQLite就行。我个人建议先用这个方案把项目跑通。我用的是GitHub上一个公开的成语大全语料大概四万多条包含了成语、拼音、解释三列。够用而且格式干净。放本地之后写个一次性的导入脚本把内容灌进SQLite之后项目主体就只跟数据库交互不再碰文本文件了。2.2 接龙规则汉字匹配不是等一等那么简单规则这东西看着简单写起来全是不起眼的坑。接龙的核心判断是上一个成语的最后一个字等于下一个成语的第一个字。你可能会说这还不简单两个字符串各取一头一尾比一下就行。但实际写起来有几个细节会绊人第一个是标点符号。用户输入“塞翁失马焉知非福”你要不要把逗号给去掉去的时候是全角还是半角如果不去取最后一个字符就取到标点了。我当时的处理是判断前先做一次清洗把全角逗号、句号、空格全部替换掉。第二个是“最后一个字”的判定。中文里有一些成语其实不是四个字“闭门羹”三个字“五十步笑百步”六个字。如果代码写死“tail idiom[-1]”三个字的取到最后一个是“羹”没问题六个字的取到“步”也没问题。所以不能默认成语都是四个字取字逻辑要跟长度无关就是字符串的末尾字符。第三个是相等判断的粒度。你要比较的是单个汉字python里直接取值再比较就行不需要正则也不需要字符集转换。python3默认就是unicode中文比较不会出问题。python2时代才会遇到编码地狱现在环境干净太多了。第四个是去重。同一个成语用户如果重复输入到底算不算有效我的规则是不算直接提示“这个成语用过了”。实现上在数据库里建一个used记录表或者更轻量一点在内存里维护一个set每轮加一个。2.3 游戏流程设计一次完整对局是怎么转起来的拿我自己定的规则举例整局游戏的流程是这样的程序先从数据库随机抽一个成语作为起始成语展示给玩家。玩家输入一个成语。程序校验是否非空是否在词库中是否已经用过首字是否等于上一成语的尾字。校验通过轮到AI接龙。AI从数据库里搜索“首字等于玩家成语尾字”且“没有使用过”的成语随机挑一个输出。如果AI找不到能接的成语AI认输玩家获胜。如果玩家在规定条件内无法接上玩家输掉游戏结束。把对局记录写进数据库。这个流程没有做太复杂的难度控制AI的策略是“只要有能接的就随机挑一个”。对于新手项目来说这个策略已经够了。你要是想做得更有挑战性一些可以让AI优先挑那些“接下去可能性更少”的成语来增加玩家的思考难度这个属于进阶玩法我不建议第一版就上。3. 数据库连接与持久化实操3.1 从零连上SQLite真正最少的三步前面铺垫完了到这里才到这个项目真正的主角——数据库连接。用sqlite3连接一个数据库核心操作就三步import sqlite3 conn sqlite3.connect(idiom_game.db) cursor conn.cursor()第一行导入驱动第二行连接数据库。你注意sqlite3.connect这一步实际上做了两件事如果“idiom_game.db”这个文件存在就打开它如果不存在就新建一个。数据库文件不需要你提前手动创建这跟MySQL完全不一样。所以你看所谓“python连接数据库”底层就是把python进程和数据库引擎之间的通道建立起来。SQLite这个通道是直接走文件的MySQL这个通道是走网络的。理解了这一层后面换数据库你就不慌换的无非是通道的建立方式SQL本身没有质变。第三行拿到的cursor是游标你可以把它理解成“在数据库文件里写写画画的笔”。所有SQL语句都通过这个游标去执行。连接用完记得关。别忘了commit这个是新手最常踩的坑执行了insert但忘了提交事务程序退出后数据没写进文件白忙一场。SQLite默认是手动提交事务你执行完写操作后必须调用conn.commit()数据才算真正落盘。3.2 表结构设计成语库和游戏记录各司其职数据库不是一张表塞就完事了。这个项目我设计了四张表每张表管一件事idioms成语词库存成语原词、首字、尾字、拼音。game_records每局游戏的基本信息比如开始时间、结束时间、最终连了多少个成语。game_details每一轮的明细谁接的、接了什么成语、这是第几轮。used_idioms本局游戏哪些成语已经被用过了防止重复。为什么要把“游戏记录”拆成game_records和game_details两张表这是数据库设计里最常见的“一对多”关系。一局游戏有多个轮次如果把所有轮次塞进一行字段会非常冗余且混乱。拆开之后想查“第2局游戏总共接了多少轮”就是一条count查询的事。建表SQL长这样CREATE TABLE IF NOT EXISTS idioms ( id INTEGER PRIMARY KEY AUTOINCREMENT, idiom TEXT NOT NULL UNIQUE, first_char TEXT NOT NULL, last_char TEXT NOT NULL, pinyin TEXT ); CREATE TABLE IF NOT EXISTS game_records ( id INTEGER PRIMARY KEY AUTOINCREMENT, started_at TEXT NOT NULL, ended_at TEXT, total_rounds INTEGER DEFAULT 0, winner TEXT ); CREATE TABLE IF NOT EXISTS game_details ( id INTEGER PRIMARY KEY AUTOINCREMENT, game_id INTEGER NOT NULL, round_no INTEGER NOT NULL, player_type TEXT NOT NULL, idiom TEXT NOT NULL, FOREIGN KEY (game_id) REFERENCES game_records(id) ); CREATE TABLE IF NOT EXISTS used_idioms ( game_id INTEGER NOT NULL, idiom TEXT NOT NULL, PRIMARY KEY (game_id, idiom) );这里有个细节值得说一下。我在idioms表里专门存了first_char和last_char两个字段而不是每次都取substr(idiom, 1, 1)去截取。这算是一个典型的“用空间换时间”的思路。成语总数四万多条多存两列字符串内存占用可以忽略不计但查询“以某字开头的成语”就变成了一条普通WHERE过滤不需要每次检索都做函数计算。在数据量大或者查询频繁的时候这种冗余字段设计能明显提升响应速度。你这个项目虽然数据量不大但养成这种设计习惯是好的。3.3 把数据写进数据库参数化查询是底线数据库建好了接下来是写入。游戏结束以后要把这局记录写进去。这里我强烈建议你养成一个习惯——永远不要用字符串拼接SQL。很多入门教程喜欢写这种代码# 反面教材别学 cursor.execute(fINSERT INTO game_records (winner) VALUES ({winner}))一旦winner里包含单引号或者特殊符号这条SQL就出问题了。更严重的是如果将来程序对外开放用户输入可以直接拼接进SQL那就是教科书式的SQL注入漏洞。游戏项目里风险不大但习惯必须是好习惯。正确写法是参数化查询cursor.execute( INSERT INTO game_records (started_at, ended_at, total_rounds, winner) VALUES (?, ?, ?, ?), (started_at, ended_at, total_rounds, winner) )问号是占位符后面的元组是实际传进去的值。python的sqlite3驱动会负责把值安全地转义和填充。这一套同样适用于查询cursor.execute( SELECT idiom FROM idioms WHERE first_char ? AND idiom NOT IN (SELECT idiom FROM used_idioms WHERE game_id ?), (last_char, game_id) )执行之后记得commit然后就可以通过cursor.rowcount或者lastrowid来确认写入结果。3.4 切到MySQL连接方式变了其余大同小异如果你是想学企业里更主流一点的方案那一开始就可以选MySQL pymysql。区别主要体现在“连接”这一步import pymysql conn pymysql.connect( host127.0.0.1, port3306, userroot, passwordyour_password, charsetutf8mb4, databaseidiom_game, connect_timeout5 ) cursor conn.cursor()注意几个跟SQLite不一样的点需要指定host和port因为MySQL是个独立的网络服务不像SQLite那样直接读文件。charset要指定utf8mb4不然中文存进去容易乱码。connect_timeout是连接超时时间单位秒。如果连不上5秒内快速报错而不是卡住不动。这个参数在实际生产环境里很有用数据库服务不健康的时候快速失败好过失联卡死。需要先手动创建database不能像SQLite那样“不存在就自动新建”。建表和增删改查部分除了占位符从问号变成了% spymysql默认风格其他几乎一模一样。你只要把SQLite版代码里的连接部分换掉再把?换成%s项目基本就能在MySQL上跑。条例说的“python数据库迁移”比想象中简单多了。4. 完整代码串一遍从头到尾能跑起来的方案4.1 项目文件结构先把文件结构列出来这样后面看代码的时候心里有数idiom_game/ ├── main.py # 主程序入口 ├── db.py # 数据库连接与初始化 ├── idiom_repo.py # 成语相关的数据访问函数 ├── game.py # 游戏核心逻辑 ├── init_data.py # 一次性导入成语数据脚本 ├── idiom.txt # 成语源文件 └── idiom_game.db # SQLite数据库文件自动生成这一层文件拆分是刻意的。db.py负责连接和建表idiom_repo.py负责SQL操作game.py不直接写SQL而是调用repo层的函数。这样分层的意义在于哪天你想把SQLite换成MySQL只需要改db.py和idiom_repo.pygame.py完全不用动。这就是分层设计的好处。4.2 核心代码逐段拆解先看db.py负责连接和建表import sqlite3 import os DB_PATH idiom_game.db def get_connection(): conn sqlite3.connect(DB_PATH) conn.row_factory sqlite3.Row return conn def init_db(): conn get_connection() cursor conn.cursor() cursor.execute( CREATE TABLE IF NOT EXISTS idioms ( id INTEGER PRIMARY KEY AUTOINCREMENT, idiom TEXT NOT NULL UNIQUE, first_char TEXT NOT NULL, last_char TEXT NOT NULL, pinyin TEXT ) ) cursor.execute( CREATE TABLE IF NOT EXISTS game_records ( id INTEGER PRIMARY KEY AUTOINCREMENT, started_at TEXT NOT NULL, ended_at TEXT, total_rounds INTEGER DEFAULT 0, winner TEXT ) ) cursor.execute( CREATE TABLE IF NOT EXISTS game_details ( id INTEGER PRIMARY KEY AUTOINCREMENT, game_id INTEGER NOT NULL, round_no INTEGER NOT NULL, player_type TEXT NOT NULL, idiom TEXT NOT NULL, FOREIGN KEY (game_id) REFERENCES game_records(id) ) ) cursor.execute( CREATE TABLE IF NOT EXISTS used_idioms ( game_id INTEGER NOT NULL, idiom TEXT NOT NULL, PRIMARY KEY (game_id, idiom) ) ) conn.commit() conn.close()有一点值得展开说就是conn.row_factory sqlite3.Row这一行。默认情况下sqlite3查询返回的每一行是元组你得用row[0]、row[1]这样按位置取数据一旦SQL里字段顺序改了代码就崩了。设置row_factory之后每一行变成了类字典对象可以通过row[idiom]这样按列名取数据。健壮性高很多可读性也更好。再看idiom_repo.py里的核心数据访问函数import random from db import get_connection def count_idioms(): conn get_connection() cursor conn.cursor() cursor.execute(SELECT COUNT(*) FROM idioms) count cursor.fetchone()[0] conn.close() return count def get_random_idiom(): conn get_connection() cursor conn.cursor() cursor.execute(SELECT idiom FROM idioms ORDER BY RANDOM() LIMIT 1) row cursor.fetchone() conn.close() return row[idiom] if row else None def find_idioms_by_first_char(first_char, exclude_list): conn get_connection() cursor conn.cursor() sql SELECT idiom FROM idioms WHERE first_char ? params [first_char] if exclude_list: placeholders ,.join([?] * len(exclude_list)) sql f AND idiom NOT IN ({placeholders}) params.extend(exclude_list) cursor.execute(sql, params) rows cursor.fetchall() conn.close() return [row[idiom] for row in rows] def is_exist(idiom): conn get_connection() cursor conn.cursor() cursor.execute(SELECT COUNT(*) FROM idioms WHERE idiom ?, (idiom,)) count cursor.fetchone()[0] conn.close() return count 0这段代码里有几个值得抄进笔记的写法。ORDER BY RANDOM() LIMIT 1是SQLite里随机取一行的高频写法MySQL里对应的是ORDER BY RAND() LIMIT 1原理都一样就是让数据库先随机排序再取第一条。exclude_list的处理是动态拼SQL参数的典型场景。因为占位符数量跟传进来的list长度有关没法写成固定SQL所以用字符串生成?,?这种形式的占位符。注意这里我做的是“参数化查询”而非直接拼字符串虽然占位符是动态生成的但值依然是通过参数传进去的安全性没有问题。然后是game.py游戏核心逻辑。这一层只关注游戏规则不关心SQL细节import datetime import random from idiom_repo import (count_idioms, get_random_idiom, find_idioms_by_first_char, is_exist) class IdiomGame: def __init__(self): self.game_id None self.total_rounds 0 self.used_idioms set() self.winner None def start(self): first get_random_idiom() if not first: raise RuntimeError(词库为空请先导入成语数据) self.used_idioms.add(first) self.total_rounds 1 print(f游戏开始起始成语{first}) return first def player_move(self, idiom): idiom idiom.replace(, ).replace(,, ).replace(。, ).replace( , ) if self.total_rounds 1 and len(self.used_idioms) 1: last_char self.get_last_idiom_char() else: last_char self.get_last_idiom_char() # 简化写法上面两个分支实际一样这里保留来示意去重逻辑位置 if len(idiom) 0: return False, 输入为空 if not is_exist(idiom): return False, 词库中不存在这个成语 if idiom in self.used_idioms: return False, 这个成语已经用过了 if idiom[0] ! last_char: return False, f首字必须是“{last_char}” self.used_idioms.add(idiom) self.total_rounds 1 return True, 接龙成功 def get_last_idiom_char(self): last_idiom list(self.used_idioms)[-1] return last_idiom[-1] def ai_move(self): last_char self.get_last_idiom_char() candidates find_idioms_by_first_char(last_char, list(self.used_idioms)) if not candidates: self.winner player return None, AI认输没有能接上的成语了 ai_choice random.choice(candidates) self.used_idioms.add(ai_choice) self.total_rounds 1 return ai_choice, fAI接{ai_choice}最后是main.py把游戏流程串起来import datetime from db import init_db, get_connection from game import IdiomGame from idiom_repo import count_idioms def save_game_result(game): conn get_connection() cursor conn.cursor() now datetime.datetime.now().strftime(%Y-%m-%d %H:%M:%S) cursor.execute( INSERT INTO game_records (started_at, ended_at, total_rounds, winner) VALUES (?, ?, ?, ?), (now, now, game.total_rounds, game.winner or draw) ) game.game_id cursor.lastrowid conn.commit() conn.close() def main(): init_db() print(f当前词库共 {count_idioms()} 条成语) game IdiomGame() game.start() while True: user_input input(轮到你了请输入成语输入quit退出).strip() if user_input.lower() quit: game.winner quit break ok, msg game.player_move(user_input) if not ok: print(接龙失败, msg) continue save_game_result(game)这段代码没有把每一轮明细写进game_details我在下面补充一下写入明细分录的逻辑这个属于代码的增强版本核心流程已经跑通了明细记录只是锦上添花。4.3 运行实测记录我实际跑了一局测试数据库导入四万条成语后随机开局“马到成功”玩家输入“功成名就”AI接“就地取材”玩家再接“材大难用”AI接“用武之地”。整个交互过程没有卡顿SQL查询响应都是毫秒级。有一点实测之后印象特别深get_random_idiom()用ORDER BY RANDOM()取随机成语四万多条数据下仍然秒出说明这个方案的性能完全没有问题。但如果你把成语库扩展到百万级这个写法会变慢因为数据库需要给所有行生成随机数再排序。到那时候可以考虑用“随机取id再查数据”的方式绕过全表排序这个属于后话了。5. 常见问题与排查技巧实录5.1 新手高频坑编码、安装、路径我朋友在跑这个项目的时候前前后后踩了得有七八个坑我挑几个典型的出来说说。第一个控制台输出中文乱码。这事情在Windows上特别常见。程序运行正常逻辑也对就是打印出来的成语变成了一堆乱码。排查方向一般是两个一是python源文件编码没声明python3默认源码是UTF-8编码正常不该出问题但如果你的编辑器默认存成了GBK那就会乱。二是Windows控制台默认代码页问题用chcp 65001切换成UTF-8代码页就能解决。第二个初始化脚本跑完了启动游戏提示“词库为空”。大概率是数据库文件路径对不上。init_data.py和main.py的工作目录不一致一个写入的是A路径下的idiom_game.db另一个读的是B路径下的。解决方式是统一用绝对路径或者在代码里基于项目根目录拼接DB_PATH不要依赖“当前所在目录”。第三个python环境没配好或者装不上pymysql。这个属于环境问题把pycharm的解释器路径确认好用pip装依赖的时候注意是装到哪个python环境里了。很多人电脑上装了不止一个python终端敲pip是Python3.8pycharm解释器用的是3.11自然装不上。用python -m pip install pymysql这种命令格式能避开一些尴尬。5.2 进阶问题连接不上、超时、数据更新第四个MySQL连接超时。如果你切到MySQL连不上数据库时默认会等很久才报错。所以我在连接参数里特意写了connect_timeout55秒内连不上立刻失败方便快速定位是网络问题还是账号问题。生产环境里这个参数更关键数据库一旦出问题应用不能跟着无休止地挂着。第五个想给词库增加新成语。如果直接往idioms表里insert发现报“UNIQUE constraint failed”那是因为我建表时给idiom字段加了UNIQUE约束。这其实是个保护机制防止词库出现重复数据。如果你确实想更新成语的拼音或解释应该用INSERT OR REPLACESQLite或者ON DUPLICATE KEY UPDATEMySQL这种upsert语义。第六个游标未关闭导致的“database is locked”。严格来说SQLite支持多连接并发读但只有一个连接能写。如果你在某处忘了关闭连接就开新连接去写偶尔会遇到“database is locked”的报错。写代码的时候记得把连接和游标关闭操作放在finally里或者用with语句自动管理。现象可能原因排查方法中文乱码源码编码不对 / 控制台代码页不对查看文件编码chcp 65001数据库文件找不到工作目录不一致用绝对路径 / 拼接项目根路径数据写入后重启丢失忘了commit检查事务提交commit后再close查询无结果返回None表中无数据 / 首字字段没写入检查导入脚本确认first_char有值MySQL连接不上服务没起 / 账号错 / 端口不对先ping再telnet再连逐层排查写在最后这个项目做完之后我再回头看python和数据库的关系理解完全不一样了。之前学的那些列表、字典、循环是在内存里折腾数据程序一关烟消云散。数据库把这个“临时工”变成了“正式工”数据存下来了程序的状态跨会话持续了整个软件的完成度瞬间上了一个档次。成语接龙本身玩法简单但它串起来的东西一点都不简单字符串清洗、状态去重、随机算法、数据库设计、SQL查询优化还有基础的软件分层思维。这一套下来你再去学django写后端会发现很多东西是相通的。最后再分享一个小技巧。成语接龙里有一个坑是“多音字”。比如“行”字可以做xíng也可以做háng字面上首尾一样读音接不上。严谨的玩法应该用拼音做接龙校验而不是用汉字。这个拓展方向我还没动工等哪天真有闲工夫准备在成语库里加上拼音字段把接龙规则升级成拼音匹配那又是一层新的优化空间。反正数据库表已经建好了加个字段不是什么难事。这个项目最让我满意的就是它留下了足够多可以继续折腾的钩子。