Python+SQLite仿银行系统实战：事务、精度与并发控制全解析

简介这是一套仿银行系统的C# WinForms完整示例项目面向初学C#窗体开发及数据库编程的读者可帮助理解银行存取款、账户管理、交易记录等核心业务的基本实现思路是一个典型的教学型案例。压缩包共44个文件体积仅257KB包含11个C#源文件、窗体资源文件、数据库文件.mdf/.ldf、可直接运行的.exe程序以及解决方案文件、界面预览图和文本说明文件组织覆盖实体类、数据访问层与多个业务窗体并附有SQL数据目录和升级报告便于对照学习整体项目结构。资源目前已有6237人浏览学习。通过这套源码读者不仅可以掌握分层架构、界面事件处理和SQL数据操作等关键技能还能借助附带的数据库脚本与运行程序快速验证效果其轻量体积和清晰模块划分也适合作为课程设计或入门项目的直接参考对理解银行类管理系统从数据层到表现层的完整闭环有切实帮助。1. 仿银行系统一个 SQLite 文件装下银行核心业务仿银行系统最花时间的往往不是界面好不好看而是怎么保证一笔转账要么两边账户都更新、要么什么都不发生。这套基于 Python Tkinter SQLite 的仿银行系统把开户、存款、取款、转账、流水查询和对账全部压缩在一个数据库文件里业务闭环完整数据库事务、金额精度、并发锁这几个经典问题都能亲手摸到。适合刚学完 Python 基础、想要一个能从头运行到结束的实战项目的开发者也适合需要参考完整业务代码的从业者。跟着后面几章把代码跑通你会理解为什么余额字段不能用浮点数、为什么转账必须包事务、为什么卡号要带校验位。2. 数据建模与技术选型账户表和流水表定下全部家底银行系统的核心数据是账户和资金变动不是用户资料管理。数据模型直接决定业务逻辑好不好写也决定后面排查问题方不方便。我搭这套系统时只建了两张表账户表保存当前有多少钱交易流水表保存钱是怎么变成现在这样的再加一个复合索引支撑高频查询就够把业务跑顺。2.1 账户表卡号、余额与状态域的字段设计账户表是整个系统的唯一事实来源。字段不多但每个都有讲究我先把建表语句列出来CREATE TABLE IF NOT EXISTS accounts ( account_id INTEGER PRIMARY KEY AUTOINCREMENT, account_no TEXT NOT NULL UNIQUE, customer_name TEXT NOT NULL, id_card TEXT NOT NULL, phone TEXT, balance_cents INTEGER NOT NULL DEFAULT 0 CHECK (balance_cents 0), status TEXT NOT NULL DEFAULT NORMAL CHECK (status IN (NORMAL, FROZEN, CLOSED)), created_at TEXT NOT NULL DEFAULT (datetime(now, localtime)) );这段建表语句里有几个容易被新手忽略的点。account_no 用 TEXT 而不是 INTEGER因为卡号是字符串逻辑可以是 16 位或 19 位超出整数安全范围后前端 JavaScript 处理大整数会掉精度用 TEXT 存储也方便做模糊查询。balance_cents 用 INTEGER 存分所有业务代码按整数分计算配合 CHECK 约束保证余额不会出现负数这比在代码里到处写 if 判断要可靠得多。status 字段是账户的生命周期状态NORMAL 才能存取款和转账FROZEN 用于冻结异常账户CLOSED 是销户。为什么不用布尔值因为后期大概率要扩展挂失止付这类状态TEXT 枚举的可扩展性更好。created_at 的默认值用了 datetime(now, localtime)。SQLite 的 UTC 时间函数会默认晚 8 个小时个人项目直接用本地时间排错时能少走弯路。如果你要对接多时区或者做生产系统这里应该改成存 UTC展示时再转换。还有一个细节account_id 用 AUTOINCREMENT 会让主键严格递增避免回收已有 ID。对账本系统来说主键一旦复用外键关联的历史记录就可能错乱所以 AUTOINCREMENT 值得保留。2.2 交易流水表一进一出都留痕字段粒度够审计账户表记录的是现在有多少钱流水表记录的是钱是怎么变成现在这样的。所有涉及余额变动的操作都要往流水表里插记录这条规则没有例外。CREATE TABLE IF NOT EXISTS transactions ( txn_id INTEGER PRIMARY KEY AUTOINCREMENT, account_no TEXT NOT NULL, txn_type TEXT NOT NULL CHECK (txn_type IN (DEPOSIT, WITHDRAW, TRANSFER_OUT, TRANSFER_IN)), amount_cents INTEGER NOT NULL CHECK (amount_cents 0), counterpart_no TEXT, balance_after_cents INTEGER NOT NULL, remark TEXT, created_at TEXT NOT NULL DEFAULT (datetime(now, localtime)) ); CREATE INDEX IF NOT EXISTS idx_txn_account_time ON transactions(account_no, created_at);流水表的设计有一个关键取舍金额方向。我见过很多新手用正负数表示存取比如存款记 100 元、取款记 -100 元看起来没毛病但到了转账场景就乱了——转出和转入是对同一个资金变动的两个视角用正负号会变成负负得正的脑筋急转弯。更稳妥的做法是 amount_cents 永远存正整数方向由 txn_type 表达。查询余额变动时再用 CASE WHEN 把 DEPOSIT 和 TRANSFER_IN 算作加、把 WITHDRAW 和 TRANSFER_OUT 算作减。balance_after_cents 是那笔交易完成后该账户的余额。这个字段属于冗余存储不是流水必需的但强烈建议留。没有它对账时要按时间顺序把每条流水重放一遍才能知道某个时刻的余额有了它查历史快照、定位异常交易都只需要一条 SQL。代价可控流水表只增不改不删冗余字段不会产生更新异常。索引建在 (account_no, created_at) 上是为了支撑查某账户某段时间的流水这个最常见查询。交易量大了以后这个复合索引的收益远大于单列索引。还有一个实际经验流水表不要建立 ON DELETE CASCADE 这类外键级联因为流水是审计证据物理删除等于销毁证据业务上只允许做冲正交易来抵消错误流水。2.3 选型对比SQLite vs MySQLTkinter vs Web 框架这套系统我选 SQLite 而不是 MySQL选 Tkinter 而不是 Flask 或 Spring Boot不是因为它们最好而是因为在这个场景下它们最合适。选型观点要有一个表来对照对比项SQLiteMySQL / PostgreSQL部署成本单文件零服务端需要安装、配置、启动守护进程事务支持支持 ACID 事务默认串行写支持行级锁、隔离级别并发能力全局写锁适合单机单写多连接并发适合生产环境数据迁移拷一个文件就能带走需要导出导入适合场景个人项目、课程设计、内部工具多用户同写、高并发、团队协作SQLite 的全局写锁意味着同一时刻只有一个事务能写库对仿银行系统这种单机演示场景完全够用而且它的事务支持是完整的BEGIN、COMMIT、ROLLBACK 一个不缺。什么时候该换 MySQL当你要做真实的多用户 Web 银行系统、多个进程同时写库变成常态时SQLite 会频繁报 database is locked那时候迁移到 MySQL 或 PostgreSQL 是自然的选择。Tkinter 同理它的 mainloop 是单线程模型不适合做高并发 GUI但恰好能逼你思考界面响应和数据库事务怎么协同这个在真实业务里同样会遇到的问题。选型边界心里要有数这套代码的重点是把业务逻辑和数据一致性写清楚不是教你生产级高可用。遇到瓶颈时知道往哪个方向迁移比一开始就上个重型框架实际得多。3. 核心流程落地开户、存取款与转账的正确姿势数据模型定好后业务层就好写了。这一章的代码都可以直接抄进工程我按项目骨架 - 开户 - 存取款 - 转账的顺序拆开讲每个函数后面跟一段代码逻辑说明。3.1 初始化建库、建表与连接管理先把项目骨架搭好。我习惯把数据库访问和业务逻辑分开界面层只调函数不直接写 SQL这样后面做自动化测试会非常轻松。# database.py import sqlite3 DB_PATH bank.db def get_conn(db_path: str DB_PATH) - sqlite3.Connection: conn sqlite3.connect(db_path, timeout5) conn.row_factory sqlite3.Row conn.execute(PRAGMA journal_mode WAL) conn.execute(PRAGMA foreign_keys ON) return conn def init_db(conn: sqlite3.Connection) - None: 执行 schema.sql 建表重复执行不报错 with open(schema.sql, encodingutf-8) as f: conn.executescript(f.read()) conn.commit()get_conn 里有三个关键点。sqlite3.connect 的 timeout5 表示当数据库被其他连接锁住时最多等 5 秒再抛错这能避免并发写冲突时界面直接卡死。conn.row_factory sqlite3.Row 让查询结果可以通过 row[account_no] 按列名访问代码可读性比元组下标好太多。PRAGMA journal_mode WAL 把默认的 rollback journal 改成 WAL 模式读操作不会被写操作阻塞对后面 GUI 里多次查询的场景有明显帮助。init_db 用 executescript 执行整个 schema.sql建表语句都带 IF NOT EXISTS所以重复初始化不会报错。有个工作习惯要养成每次改完表结构把旧的 bank.db 文件删掉重新执行一次 init_db确保从零也能建出库来。这个习惯能挡掉大部分我本地能跑、别人拉下来就报错的尴尬。3.2 开户生成的卡号为什么敢说不重复开户的核心是两件事生成一个新卡号、插入账户记录。卡号用 BIN发卡机构标识 9 位随机体 1 位 Luhn 校验位共 16 位。Luhn 校验位的作用是让输错一位数字能被立刻识别这是银行发卡的真实规则仿系统保留它能让后续做卡号输入校验时有据可依。import random import sqlite3 BIN_PREFIX 620058 def luhn_checksum(body: str) - int: Luhn 算法计算校验位body 不含校验位 digits [int(ch) for ch in body] for i in range(len(digits) - 1, -1, -2): digits[i] * 2 if digits[i] 9: digits[i] - 9 total sum(digits) return (10 - (total % 10)) % 10 def open_account(conn: sqlite3.Connection, name: str, id_card: str, phone: str) - str: cursor conn.cursor() for attempt in range(5): body f{random.randint(0, 999_999_999):09d} account_no BIN_PREFIX body str(luhn_checksum(BIN_PREFIX body)) try: cursor.execute( INSERT INTO accounts (account_no, customer_name, id_card, phone) VALUES (?, ?, ?, ?), (account_no, name, id_card, phone), ) conn.commit() return account_no except sqlite3.IntegrityError: continue raise RuntimeError(开户失败连续5次生成重复卡号)luhn_checksum 的计算过程不复杂从右往左隔位乘 2超过 9 就减 9再求和用 10 的补数作校验位。body 用 9 位随机数补零配合 BIN 前缀总共 15 位加上校验位正好 16 位。随机数范围是 0 到 999999999理论上碰撞概率很低但数据库 UNIQUE 约束是兜底捕获 IntegrityError 后只要没超过 5 次就重新生成。为什么要重试而不是直接报错因为卡号撞库对用户是不可接受的错误对系统则是小概率事件重试成本极低比通知用户请重新提交体面得多。INSERT 语句全部用 ? 占位参数杜绝 SQL 注入。这一点在后面对接 GUI 时特别重要用户输入框里的内容永远不该被拼进 SQL 字符串。另外注意开户函数里没有显式 BEGINsqlite3 模块默认在 INSERT 之前自动开启事务conn.commit() 调用时统一提交。3.3 存取款一次提交保证余额与流水同生共死存款是余额加钱加记一笔流水两个动作。两个动作必须同时成功或者同时失败这就是事务的原子性。下面以存款为例取款逻辑对称def deposit(conn: sqlite3.Connection, account_no: str, amount_cents: int) - int: if amount_cents 0: raise ValueError(存款金额必须大于0单位分) cursor conn.cursor() row cursor.execute( SELECT balance_cents, status FROM accounts WHERE account_no ?, (account_no,), ).fetchone() if row is None: raise ValueError(账户不存在) if row[status] ! NORMAL: raise ValueError(账户状态异常禁止存款) new_balance row[balance_cents] amount_cents cursor.execute( UPDATE accounts SET balance_cents ? WHERE account_no ?, (new_balance, account_no), ) cursor.execute( INSERT INTO transactions (account_no, txn_type, amount_cents, balance_after_cents, remark) VALUES (?, DEPOSIT, ?, ?, ?), (account_no, amount_cents, new_balance, 柜面存款), ) conn.commit() return new_balance存款前先查账户状态这一步不是可选的。对冻结账户放行存款后面会产生账户状态异常但资金还在增加的局面。注意这里没有显式写 BEGIN TRANSACTIONsqlite3 模块默认在 UPDATE 之前自动开启事务调用 conn.commit() 时统一提交。有个容易翻车的点如果 conn.commit() 之前抛了异常连接会保持在未提交状态后续操作会继续累积在这个事务里。这个坑的细节放在第 4 章讲。取款逻辑跟存款对称只是把 UPDATE 改成减法并多加一个余额判断if row[balance_cents] amount_cents: raise ValueError(余额不足)这个 if 判断在单连接单线程下够用但如果是多连接并发取款就得依赖事务隔离机制。单纯靠 SELECT 出来的数字做判断会有竞态条件两个连接同时读到余额 100 元同时扣 90 元余额就会变成 10 而非 20 或负值。对这个单机项目单用户不会触达这个坑但你要知道边界在哪。3.4 转账一个事务里完成两借两贷转账是仿银行系统里最有技术含量的一段从一个账户扣钱、往另一个账户加钱、写两条流水任何一个步骤失败前面做过的所有修改都必须撤销。代码里先做全部校验再做全部写操作最后一次性提交def transfer(conn: sqlite3.Connection, from_no: str, to_no: str, amount_cents: int) - None: if amount_cents 0: raise ValueError(转账金额必须大于0单位分) if from_no to_no: raise ValueError(不能给自己转账) cursor conn.cursor() src cursor.execute( SELECT balance_cents, status FROM accounts WHERE account_no ?, (from_no,), ).fetchone() dst cursor.execute( SELECT balance_cents, status FROM accounts WHERE account_no ?, (to_no,), ).fetchone() if src is None or dst is None: raise ValueError(转账账户不存在) if src[status] ! NORMAL or dst[status] ! NORMAL: raise ValueError(存在非正常状态账户禁止转账) if src[balance_cents] amount_cents: raise ValueError(余额不足) new_src src[balance_cents] - amount_cents new_dst dst[balance_cents] amount_cents cursor.execute( UPDATE accounts SET balance_cents ? WHERE account_no ?, (new_src, from_no), ) cursor.execute( UPDATE accounts SET balance_cents ? WHERE account_no ?, (new_dst, to_no), ) cursor.execute( INSERT INTO transactions (account_no, txn_type, amount_cents, balance_after_cents, counterpart_no, remark) VALUES (?, TRANSFER_OUT, ?, ?, ?, ?), (from_no, amount_cents, new_src, to_no, 转账支出), ) cursor.execute( INSERT INTO transactions (account_no, txn_type, amount_cents, balance_after_cents, counterpart_no, remark) VALUES (?, TRANSFER_IN, ?, ?, ?, ?), (to_no, amount_cents, new_dst, from_no, 转账收入), ) conn.commit()转账的每个校验都不能少账户存在性、双方状态、余额、自己转自己。尤其是自己转自己这个边界真实银行系统里会被特殊处理仿系统里直接抛 ValueError 是最清晰的做法。校验全部通过后四个写操作两条 UPDATE、两条 INSERT在同一个连接上执行期间没有 commit。如果中途抛异常前面三个写操作都还没提交连接关闭时 sqlite3 会自动回滚未提交的事务从根上避免A 扣了钱 B 没到账。两条流水都记录了 balance_after_cents后续对账时能从任一笔流水的余额字段反推交易前后的资金状态。counterpart_no 把两条流水关联成一组转账对账时可以通过对手账户把它们配对。这里有个细节转账的两条流水方向不同但 amount_cents 都为正数区别只在 txn_type 上这正是第 2 章设计的体现。注意如果转账函数里需要提前返回错误务必在 return 之前 rollback 掉当前连接上挂着的隐式事务否则下一次 execute 会接着上次的未提交事务继续执行数据就会变得非常诡异。4. 避坑排查事务提交、浮点精度与并发锁的五个现场这一章写给准备照着代码跑一遍的人。我把开发过程中踩过的坑按现象 - 原因 - 解决整理成五条每一条都是花时间定位过的不是理论推导。4.1 存款成功但余额没变事务没提交现象在界面上点存款程序弹出成功提示切到查询页一看余额还是旧值。原因存款函数执行完没有显式调用 conn.commit()。sqlite3 在 execute 写语句后自动开启事务如果只 execute 不 commit本次连接内的其他查询能读到新数据但其他连接查不到。如果界面层的查询请求走的是另一个连接自然读到旧快照。还有一种情况是查询连接和写操作连接不是同一个写连接改动没提交读连接当然看不到变化。解决存款函数的最后必须有 conn.commit()同时查询和写操作尽量复用同一个连接或者每次查询前先 rollback 掉未提交事务再查。我在排错时一般直接打开 sqlite3 命令行加载同一个 bank.db 文件执行 SELECT balance_cents 验证数据是否落盘。这个习惯能省掉大量代码看着没问题但数据不对的定位时间。4.2 余额越算越不对0.1 加 0.2 不等于 0.3现象存入 0.1 元、再存入 0.2 元余额显示 0.30000000000000004导出的对账单里出现一长串小数。原因Python 的 float 是 IEEE 754 双精度浮点数0.1 和 0.2 在二进制里都是无限循环小数累加必然出现误差。凡是涉及钱的字段用 float 存储就是给自己埋雷。这个常识教科书里讲过但在实际项目里仍然大量翻车因为界面输入框天然以元为单位给人看拿到输入值随手一存就是 float。解决所有余额和交易金额统一用整数分存储界面输入时做转换。用户在输入框填 100.50 元代码里 int(round(float(input_text) * 100)) 转成 10050 分取出来显示时再用 f{cents // 100}.{cents % 100:02d} 转回元。SQLite 表结构里已经用 INTEGER 存分业务层要守住的底线是任何地方都不要让 float 参与余额计算。int(round(float(input_text) * 100)) 仍有理论精度损失更严格的实现是把输入字符串按小数点拆开再拼成整数。对个人项目 round 方案够用但想要零误差字符串拆分才是正解。4.3 转账时程序中断A 扣了钱 B 没到账现象转账过程中代码抛异常比如后半段校验失败捕获异常后查询发现 A 的余额已经减少B 的余额没变。原因事务边界没包住。比如在转账函数里先执行了扣 A 的 UPDATE然后提前调用了 conn.commit()再去执行加 B 的 UPDATE。前面的 commit 已经把扣款固化成永久数据后面的操作再抛异常就无法和前面的扣款一起回滚。本质是把单语句提交误解为整事务提交。解决转账全过程不许提前 commit只在全部 UPDATE 和 INSERT 完成后 commit 一次。更稳妥的做法是显式 BEGIN IMMEDIATE把事务边界写在代码里conn.execute(BEGIN IMMEDIATE) try: # 所有余额更新和流水插入 conn.commit() except: conn.rollback() raiseBEGIN IMMEDIATE 会立刻拿到写锁避免两个转账事务同时进入后互相踩踏。try/except 保证异常时一定 rollback不会再出现半截事务。从那以后我写任何涉及多表写操作的代码都强制套这个模板。4.4 点按钮后程序没响应像卡死了一样现象界面上点转账窗口直接白屏无响应过十几秒才恢复期间标题栏出现未响应。原因Tkinter 的 mainloop 是单线程事件循环按钮回调里执行耗时操作数据量稍微大一点的查询、CSV 导出等会堵住事件循环界面就失去响应。仿银行系统的数据量不大但如果对账单跨了三年流水且同步导出卡顿一定会出现。解决把耗时操作放到独立线程里线程完成后用 queue 或 after 机制把结果投递回主线程。常见做法是import threading import queue result_q queue.Queue() def on_transfer_click(): def worker(): try: transfer(conn, from_no, to_no, amount_cents) result_q.put((ok, None)) except Exception as e: result_q.put((error, str(e))) threading.Thread(targetworker, daemonTrue).start() root.after(100, poll_result) def poll_result(): try: status, msg result_q.get_nowait() # 更新界面 except queue.Empty: root.after(100, poll_result)注意 SQLite 连接默认不能跨线程使用。worker 线程里要么新建连接要么给每个线程配独立的连接。我一般会在 worker 里新开一个连接做写操作做完关闭避免和主线程的连接互相干扰。4.5 多窗口同时操作报 database is locked现象开两个管理窗口一个做转账、一个做开户其中一个报 sqlite3.OperationalError: database is locked。原因SQLite 同一时间只允许一个写事务。第二个连接尝试写时会等待超过 connect 的 timeout 就抛错。个人项目里最常见的触发场景是某个连接上有一个事务没提交另一个连接又发起写操作。解决设置合理的连接超时sqlite3.connect 的 timeout 参数并且坚持事务要短、用完及时提交。还有一个容易被忽略的点WAL 模式读写不互斥但写写仍然互斥所以 journal_mode 换成 WAL 不能解决两个写事务的竞争它解决的是一个写一个读的阻塞问题。如果无论如何都锁死检查代码里有没有遗漏的 BEGIN 或没有 commit 的事务——用 conn.in_transaction 属性可以快速确认当前连接上是否挂着未提交事务。5. 进阶对账把交易流水变成可审计的报表跑通存取款和转账之后系统已经有能力产生真实的业务数据了。接下来要回答的问题是怎么向自己证明账户余额没错靠的不是界面上的绿色数字而是用流水独立复算把结果导成对账单给第三方看。5.1 复算对账拿流水反推每个账户的余额对账的核心是一段 SQL用流水表反推每个账户应当有的余额再去和账户表的当前余额比对。不一致的就是问题账户SELECT a.account_no, a.balance_cents AS current_balance, COALESCE(SUM( CASE WHEN t.txn_type IN (DEPOSIT, TRANSFER_IN) THEN t.amount_cents WHEN t.txn_type IN (WITHDRAW, TRANSFER_OUT) THEN -t.amount_cents ELSE 0 END ), 0) AS calculated_flow FROM accounts a LEFT JOIN transactions t ON t.account_no a.account_no GROUP BY a.account_no, a.balance_cents HAVING current_balance ! calculated_flow;这段 SQL 的意图是把账户表里的余额和流水表里的累计变动金额做对比。LEFT JOIN 保证没有流水的新账户也能出现在结果集里COALESCE 把 NULL 变成 0。查询结果不为空就说明有账户的余额不是流水推导出来的要么是手工改了库要么是某条流水漏写、错写、重复写。对账时有个前提流水里的金额方向规则必须统一。DEPOSIT 和 TRANSFER_IN 记正WITHDRAW 和 TRANSFER_OUT 记负如果某条流水违反这个规则对账会立刻暴露。一旦发现对不上最有效的排错手段是查那个账户所有流水的 balance_after_cents 序列看哪一笔的余额跳变异常——这就是当初冗余存储这个字段的回报。举个例子某账户转账后 balance_after_cents 应该是上一笔余额减转出金额如果发现某个值对不上基本可以把问题锁定到那一笔交易的时间点上。5.2 导出对账单CSV 的中文编码与时间边界对账结果要给人看一般导出 CSV。导出逻辑不复杂坑都在编码和时间边界上。下面是一个可直接用的导出函数import csv def export_statement(conn, account_no, start_date, end_date, filepath): cursor conn.cursor() cursor.execute( SELECT created_at, txn_type, amount_cents, balance_after_cents, COALESCE(counterpart_no, ), COALESCE(remark, ) FROM transactions WHERE account_no ? AND created_at ? AND created_at ? ORDER BY created_at, (account_no, start_date 00:00:00, end_date 23:59:59), ) rows cursor.fetchall() with open(filepath, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerow([交易时间, 交易类型, 金额(分), 余额(分), 对手账户, 备注]) writer.writerows(rows)两个容易踩的坑。第一CSV 用 Excel 打开中文乱码解决方法是 encodingutf-8-sig带上 BOM 头。如果你用 utf-8 直接写程序打开没错Excel 打开大概率乱码。第二时间边界要用半开区间 [start, end) 的写法。上面 SQL 用 start 00:00:00 和 end 23:59:59但实际数据里如果有 23:59:59.500 这类时间戳会被 23:59:59 的边界条件漏掉。更严谨的写法是传入 end_date 的次日零点SQL 里用 created_at 次日 00:00:00。这样结束边界不会卡在秒级别的精度上。导出之后把导出的 CSV 和 SQL 复算的结果做一次交叉核对逐行检查 balance_after_cents 是否等于上一行的 balance_after_cents 加减本行金额。看起来多此一举但能挡住代码改了字段、导出逻辑忘了同步这类隐蔽回归。对账模块是仿银行系统的安全网花在这上面的时间都是值得的。6. 最后一个技巧自动化回归测试锁定业务正确性每次改完业务代码怎么快速验证老功能没被改坏我建议写一个回归测试脚本用内存数据库把开户、存款、取款、转账、对账整条链路跑一遍。内存数据库测试跑完自动消失不会污染开发数据跑起来也快import sqlite3 import services import database SCHEMA_SQL open(schema.sql, encodingutf-8).read() RE_CONCILIATION_SQL SELECT a.account_no, a.balance_cents, COALESCE(SUM(...), 0) AS calc FROM accounts a LEFT JOIN transactions t ON t.account_no a.account_no GROUP BY a.account_no, a.balance_cents HAVING a.balance_cents ! calc; def run_regression(): conn sqlite3.connect(:memory:) conn.row_factory sqlite3.Row conn.executescript(SCHEMA_SQL) conn.commit() acc_a services.open_account(conn, 客户甲, A_ID_CARD, 13800000000) acc_b services.open_account(conn, 客户乙, B_ID_CARD, 13900000000) assert services.deposit(conn, acc_a, 100_00) 100_00 assert services.transfer(conn, acc_a, acc_b, 30_00) is None rows conn.execute(SELECT * FROM transactions).fetchall() assert len(rows) 3 # 1笔存款 2条转账流水 assert services.withdraw(conn, acc_b, 10_00) 20_00 # 异常路径余额不足必须抛异常 try: services.transfer(conn, acc_b, acc_a, 999_00) assert False, 余额不足应该抛异常 except ValueError: pass # 对账流水复算余额必须与账户余额一致 bad conn.execute(RE_CONCILIATION_SQL).fetchall() assert len(bad) 0 print(回归测试通过) conn.close()这个脚本的断言覆盖了正常路径和异常路径。正常路径里存款后余额是 100 元分转账后 A 剩 70 元、B 有 30 元再取款 10 元后 B 是 20 元。异常路径里余额不足必须抛 ValueError如果系统没有抛异常测试直接失败。最后对账 SQL 保证流水和余额始终对平。从那以后我每次改表结构、改业务函数都强制先跑一遍这段回归脚本再打开 GUI 手工点一遍。不是不相信自己而是这种账务系统一旦出错排查成本远高于写测试的成本。这套资源把全部源码、建表脚本和回归测试整理成了可直接运行的工程下载后按 README 从零跑一遍比只看截图直观得多。希望帮到你。本文还有配套的精品资源点击获取