Tkinter+SQLite构建企业级桌面数据管理系统：从架构到实践

1. 别被标题里的“企业级”吓退：这个组合的真正落点在哪

先交代一下背景。这个系列写到第18篇，前面聊了大量 Tkinter 控件、布局、事件绑定和界面美化，不少读者留言问我“界面做出来了，东西往哪存？”这正好戳中了桌面应用最尴尬的空白区：Demo 阶段数据可以写死在列表里，一旦要做成能给别人用的系统，没有持久化就是空中楼阁。

我在这篇文章里给出一套自己反复验证过的方案：用 Tkinter 做界面层，SQLite 做存储层，构建一个能支撑小型团队日常业务流转的桌面数据管理系统。它的范围包括入库、出库、商品资料维护、基础查询统计这些典型模块——看起来不炫，但结构上把界面、业务、数据访问拆干净了，后面扩展其他模块只是复制模板的事。

为什么这种组合值得认真做？因为现实里大量内部工具、门店终端、仓库辅助系统、生产车间记录台，运行环境就是一台 Windows 电脑加一个局域网，用户数量少则一两人、多则十几人。这种场景用浏览器那套太重，上 MySQL 要配服务端又要管账号权限；用 Excel 管理又会在多人改同一份文件时互相覆盖。Tkinter 加 SQLite 刚好卡在中间：Python 环境能跑起来就直接能用，不用装额外运行时，而且单文件数据库对备份、迁移、拷贝都非常友好。

不过既然标题里写了“企业级”，我得先花点篇幅把这三个字解释清楚，免得有人拿着这套代码去接完全不适合的项目，回头骂方案不行。我理解的企业级桌面应用，首先是数据不能丢、不能错乱，其次是操作流程上有边界处理，再次是能应对多台机器偶尔同时访问的情况。它和互联网高并发系统要解决的“企业级”是两个物种，前者考验工程化质量，后者考验分布式架构能力，概念千万别混。

我的建议是：如果你的场景是单机或很少量并发、数据量在几十万行以内、用户群体偏内部工具型，那这套技术栈是当下效率最高的选择之一。反之，如果你预判未来会有几十个人在不同地域同时高频写入、数据表过亿、需要复杂权限审计，那就不要在 Tkinter 上继续投入，趁早换 B/S 架构加专业数据库，这不是本文能覆盖的范畴。

2. 动手之前先看两条铁律：连接生命周期与单文件数据库的并发边界

2.1 决定 SQLite 工作模式的是连接数，不是线程数

很多人在 SQLite 上翻车的第一个坑，不是语法，而是连接生命周期的管理。由于 SQLite 本质是嵌入式的文件型数据库，它对“写”操作有全局锁：某个时刻只允许一个连接真正写入，其他写入请求只能排队等待。这里的核心不是“不能开多线程”，而是你要明确控制有多少个写连接。

我在项目里的做法是所有数据访问共用同一个连接对象，并给这个连接加一个线程锁，任何线程要操作数据库前先拿到锁。听起来有点笨，但极大减少了“database is locked”这类错误的概率。

code复制import sqlite3
import threading

class DatabaseManager:
    _instance = None
    _lock = threading.Lock()

    def __new__(cls, db_path):
        if cls._instance is None:
            with cls._lock:
                if cls._instance is None:
                    cls._instance = super().__new__(cls)
                    cls._instance._init_connection(db_path)
        return cls._instance

    def _init_connection(self, db_path):
        # check_same_thread=False 表示连接会被多个线程调用，需要自己保证线程安全
        self.conn = sqlite3.connect(db_path, timeout=10, check_same_thread=False)
        self.conn.row_factory = sqlite3.Row
        self.conn.execute("PRAGMA journal_mode=WAL")
        self.thread_lock = threading.Lock()

    def execute(self, sql, params=()):
        with self.thread_lock:
            try:
                cursor = self.conn.execute(sql, params)
                self.conn.commit()
                return cursor
            except sqlite3.Error as e:
                self.conn.rollback()
                raise e

这段代码的核心不是单例模式本身，而是 timeout=10 和 PRAGMA journal_mode=WAL 这两个细节。前者指定了拿不到写锁时最多等 10 秒，避免并发情况下直接抛异常；后者把数据库默认的 rollback journal 改成了 Write-Ahead Logging，让读操作和写操作可以并行，实际体验会顺滑很多。

2.2 业务表要不要用自增主键，我后来改了主意

再说说建表时的通病。最早做这类系统，所有表的 id 字段我都喜欢写 INTEGER PRIMARY KEY AUTOINCREMENT，觉得省事。后来在给一个库存系统做多端数据合并时发现，AUTOINCREMENT 会产生全局自增的 id，当你从旧库导入数据、或以后想把数据迁移到别的表结构时，id 碰撞和重新映射会让人想摔键盘。

现在我的建议反而是：核心业务表用一种生成规则简单、不依赖数据库自增的字符串主键，比如“PR + 年月日 + 4位随机码”。这样做有几个明显的好处：新增数据时不依赖上次插入的记录，数据可以从 Excel 批量导入再补主键，多台机器离线录入后也能通过唯一主键做合并。

code复制CREATE TABLE IF NOT EXISTS products (
    product_id TEXT PRIMARY KEY,
    product_name TEXT NOT NULL,
    category TEXT,
    spec TEXT,
    unit TEXT DEFAULT '件',
    stock INTEGER DEFAULT 0,
    safety_stock INTEGER DEFAULT 0,
    purchase_price REAL DEFAULT 0,
    sale_price REAL DEFAULT 0,
    supplier TEXT,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

字段规划上，我倾向于把库存数量、安全库存这类将来要参与计算的字段单独拆成 INTEGER，价格类统一用 REAL，不要把型号、备注、单位这些可选信息揉进一个字段里用分隔符储存——你当时确实省事了，后面写统计 SQL 的时候会痛苦百倍。

2.3 别用字符串拼接 SQL，也别把用户输入直接塞进 SQL

这个提醒老生常谈，但在 Tkinter 项目里尤其容易翻车。原因是 Tkinter 界面拿到的所有控件值默认都是字符串，初学者习惯直接 f"INSERT INTO products VALUES('{name}', {price})"，看起来简单，一旦用户输入的文本里包含引号、百分号或者极端字符，轻则程序报错退出，重则产生 SQL 注入风险——虽然本地 SQLite 被注入的损失没有服务器端大，但数据被误删或错乱，同样是你承担不起的事故。

正确的做法是使用占位符参数化查询：

code复制def add_product(self, product_id, name, category, purchase_price, sale_price):
    sql = """
        INSERT OR REPLACE INTO products
        (product_id, product_name, category, purchase_price, sale_price)
        VALUES (?, ?, ?, ?, ?)
    """
    self.db.execute(sql, (product_id, name, category, purchase_price, sale_price))

无论你写的是 ? 还是 :name，核心是把数据和 SQL 分开，让底层去处理字符转义。这个习惯一旦养成，后面写带搜索条件、带日期范围的一切动态查询都会安全得多。

3. 从界面直接连数据库到分层重构：让写代码不再越写越乱

3.1 一开始我也把 SQL 写在按钮回调里，直到第二次改需求

第一次做这种系统时，为了图快，我直接在“保存”按钮的 command 回调里写了完整的 SQL 和 commit。功能第一次上线跑得挺好，但第二个星期需求来了：商品表要增加一个“是否启用”开关，删除商品时要做软删除而不是物理删除。这时候我面临一个选择，把所有入口的回调全部找出来，挨个修改 SQL——这些 SQL 散布在十几个方法里，其中不少是复制粘贴出来的变体，有一两处漏改了，功能就会出现诡异的数据不一致。

那一刻我确定了一个原则：界面层永远不许直接操作数据库对象，哪怕只是一个 sqlite3.connect 都不行。界面只应该做三件事：收集用户的输入、把输入打包成领域对象、调用业务层的方法并显示结果。所有 SQL 和事务逻辑收敛到 DAO（Data Access Object）层。

code复制class ProductDao:
    def __init__(self, db_manager):
        self.db = db_manager

    def query_by_keyword(self, keyword):
        sql = """
            SELECT * FROM products
            WHERE product_name LIKE ?
               OR product_id LIKE ?
               OR supplier LIKE ?
            ORDER BY updated_at DESC
        """
        fuzzy = f"%{keyword}%"
        cursor = self.db.execute(sql, (fuzzy, fuzzy, fuzzy))
        return [dict(row) for row in cursor.fetchall()]

    def soft_delete(self, product_id):
        sql = "UPDATE products SET is_active = 0 WHERE product_id = ?"
        self.db.execute(sql, (product_id,))

    def adjust_stock(self, product_id, delta):
        sql = """
            UPDATE products
            SET stock = stock + ?, updated_at = CURRENT_TIMESTAMP
            WHERE product_id = ?
        """
        self.db.execute(sql, (delta, product_id))

这样分完之后，窗口回调里的代码就从一段“看得头晕的 SQL 长诗”变成了几行通俗的调用。比如：

code复制def on_save_clicked(self):
    data = self._collect_form_data()
    self.product_dao.add_product(data)
    self._refresh_list()

3.2 一个窗口一个 Presenter 的轻量模式，别在这层过度设计

有读者问要不要引入 MVC、MVVM 之类的正式架构。Tkinter 本身没有官方推荐的架构模式，硬套复杂框架反而会大幅增加样板代码，让初学者迷迷糊糊。我采用的是一个非常轻量的分层：界面文件只负责 tk.Toplevel 或 tk.Frame 的构建，然后把每个业务动作委托给一个对应的 Presenter 对象。

这个 Presenter 不是某种重框架，而是一个普通的 Python 类，持有数据库 DAO 和当前界面的引用。用户点击某个按钮，界面调用 Presenter 的方法，Presenter 操作 DAO，完成后返回结果并让界面刷新。这种做法让你能很自然地给 Presenter 写单元测试——你把 DAO 替换成一个内存实现，跑测试时根本不需要弹出图形窗口。

3.3 从“保存成功”弹窗看事务粒度：一个动作要么全成，要么全不成

事务处理是“企业级”这三个字的分水岭。一个典型场景：入库单录入时，不仅要往 stock_records 插入一条流水，还要把 products 表的库存数量同步增加。如果只插入流水却忘了更新库存，盘点时永远对不上账；如果先更新库存但流水插入失败，你永远查不清这批货从哪进来的。这种成对操作必须放在同一个事务里。

问题是默认的 sqlite3 行为在 Python 里有点迷惑人：当你执行 INSERT 时，它可能自动开启一个隐式事务，如果你紧接着又执行其他语句，它实际上还可能沿用同一个事务；但如果你在某个中间步骤抛了异常又没有统一 rollback，数据库可能停留在一种半开半闭的状态。为了让逻辑清晰，我封装了一个专门的在 DAO 层运行多步骤操作的方法：

code复制def execute_in_transaction(self, operations):
    with self.thread_lock:
        try:
            self.conn.execute("BEGIN")
            for sql, params in operations:
                self.conn.execute(sql, params)
            self.conn.commit()
        except sqlite3.Error:
            self.conn.rollback()
            raise

新增或编辑入库单时，调用方只需要把要执行的 SQL 按顺序放到列表里：

code复制def create_stock_in(self, record_id, product_id, quantity):
    operations = [
        ("INSERT INTO stock_records (record_id, product_id, type, quantity) VALUES (?, ?, 'in', ?)",
         (record_id, product_id, quantity)),
        ("UPDATE products SET stock = stock + ? WHERE product_id = ?",
         (quantity, product_id)),
    ]
    self.db.execute_in_transaction(operations)

这样能保证“记录流水”和“更新库存”要么同时生效，要么同时回滚，不会再出现数据对不上的“半成功”状态。

4. 主界面怎么搭才像正经系统：导航树、分页列表与数据刷新

4.1 别把窗口做成一张可以无限堆控件的画布

主系统的界面我是这样拆的：左侧用 tk.PanedWindow 放导航树 ttk.Treeview，列出“商品管理”“入库管理”“出库管理”“库存查询”等模块；右侧是一个容器 Frame，根据导航选择切换不同的页面类。这个布局的最大优点是每个模块自成一个 Frame，代码不会全部堆在同一个事件回调里。

导航树的事件绑定注意别把选中行和展开节点的逻辑混在一起。我只监听 <<TreeviewSelect>> 事件，用 selection() 方法取当前选中的项目 ID，然后映射到对应页面类。为了避免做切换时残留上一次的焦点或滚动位置，我会在切换前显式 destroy() 掉旧 Frame，确保界面不会越积越卡。

code复制class MainWindow(tk.Tk):
    def __init__(self):
        super().__init__()
        self.title("企业桌面数据管理系统")
        self.geometry("1200x760")
        self._build_navigator()
        self._show_page("dashboard")

    def _on_nav_select(self, event):
        selection = self.nav_tree.selection()
        if not selection:
            return
        item_id = selection[0]
        self._show_page(item_id)

    def _show_page(self, module_id):
        for child in self.content_frame.winfo_children():
            child.destroy()
        page_class = self.page_map.get(module_id)
        if page_class:
            page_class(self.content_frame, self.db_manager).pack(fill="both", expand=True)

4.2 Treeview 展示数据时，记得设置列宽拉伸和排序状态

几乎每个业务列表都要用 ttk.Treeview。第一次开发时我发现它默认不显示表头以外的网格线、列宽也不会随窗口自适应拉伸，观感非常粗糙。我现在的处理方式是给每个列设置 stretch=True、anchor="center"，然后把具体业务列绑定到树节点上。

另外，有个高频操作是：把 Treeview 上所有子节点清空再重新填充。如果数据有几千条，清空时不推荐用 tree.delete(*tree.get_children()) 一条条删——那样在大数据量下会有明显卡顿。虽然 get_children() 返回的是元组，删除操作在 CPython 里已经做过优化，但更优雅的做法还是把查询结果控制在合理的分页范围内，一次只加载几百条，需要更多数据时再点击“下一页”。

查询结果映射到 Treeview 时，建议把业务主键或行 ID 藏在节点的 iid 里，这样后续做删除、编辑时不用再从界面上反向解析“选中行对应数据库里哪一行”，直接读取 iid 即可，逻辑干净且避免误操作。

code复制class ProductPage(tk.Frame):
    def _refresh(self):
        for item in self.tree.get_children():
            self.tree.delete(item)
        rows = self.product_dao.query_by_keyword(self.search_var.get())
        for row in rows:
            self.tree.insert("", "end", iid=row["product_id"], values=(
                row["product_id"],
                row["product_name"],
                row["category"],
                row["stock"],
                row["sale_price"],
            ))

    def _on_edit_clicked(self):
        selected = self.tree.selection()
        if not selected:
            messagebox.showwarning("提示", "请先选择一行数据")
            return
        product_id = selected[0]
        ProductEditDialog(self, product_id, self.product_dao)

4.3 表单数据校验位置要放在“收集”那一步，而不是“写库”那一步

在桌面表单里，用户总会有意无意地输入：空字符串、负数、超过精度的价格、中英文混合的编号。如果你把这些脏数据直接丢给 SQLite，虽然数据库可能因字段类型宽松而“宽容”地接收下来，但后续统计就会出现 0 库存负数、价格算错小数点之类的事故。

我的做法是在 UI 的保存回调里，加一个独立的 _validate_form() 方法，集中做以下几类检查：

• 必填字段不能为空，空白字符串要剔除首尾空格后再判断；
• 数值字段要能通过 float()，且必须大于等于 0；
• 质量编号类的字段要匹配提前定义的 regex 或长度限制；
• 供应商、分类等从下拉框选择的字段，要确认用户选的是合法值而不是随便输入的文本。

校验失败时用一条 messagebox.showwarning 把错误信息返回给用户，并顺手把焦点调到第一个非法控件上。数据一旦通过校验进入 DAO 层，内部通常就不再重复这种繁琐判断，因为我们已经假定这是业务层的“可信数据”。这样分工，DAO 里也清爽，UI 也始终有对用户反馈的唯一出口。

5. 数据库操作让窗口假死：这套线程与队列方案撑住了长任务

5.1 “卡住不动”的根因不在数据库，而在 Tk 的主循环

给一个团队做演示的时候，有人点击“从 Excel 导入库存数据”，文件有几万行，界面直接像死掉一样，标题栏都出现“未响应”提示。这里的问题不是 SQLite 能力不够，而是 Tkinter 的主循环是单线程的。你在主线程里执行一个耗时几十秒的循环加逐条插入，事件循环被堵死，鼠标点击、拖拽、重绘全都排不上队，系统看完就认为应用失去响应。

解决思路不是让 Tk 支持多线程，而是在后台工作线程里跑耗时操作，然后把结果通过线程安全的方式传回主线程更新界面。注意：Tkinter 的所有控件操作都不是线程安全的，绝对不要在后台线程里直接调用 tree.insert() 或修改 StringVar，否则会出现随机崩溃。

5.2 用 queue.Queue 做结果回传，给导入加进度显示

我的标准改造套路是：点击导入时，先把 UI 状态锁住（例如禁用按钮），启动一个 threading.Thread，后台线程逐行读取 Excel 并组装 SQL，每处理完一批记录，就把“已完成多少条”的消息放进 queue.Queue；主线程使用 after() 定时轮询这个队列，有新进度就更新进度条和状态标签。任务结束后同样通过队列发一个结束标记，主线程收到后再恢复按钮状态并刷新列表。

code复制class ExcelImportWorker(threading.Thread):
    def __init__(self, file_path, dao, msg_queue):
        super().__init__(daemon=True)
        self.file_path = file_path
        self.dao = dao
        self.msg_queue = msg_queue

    def run(self):
        total = 0
        try:
            for batch in self._read_excel_batches(self.file_path):
                self.dao.batch_insert(batch)
                total += len(batch)
                self.msg_queue.put(("progress", total))
            self.msg_queue.put(("done", None))
        except Exception as e:
            self.msg_queue.put(("error", str(e)))

def poll_queue(self):
    try:
        while True:
            msg_type, payload = self.msg_queue.get_nowait()
            if msg_type == "progress":
                self.progress_var.set(payload)
            elif msg_type == "done":
                self._unlock_ui()
                self._refresh_list()
            elif msg_type == "error":
                messagebox.showerror("导入失败", payload)
    except queue.Empty:
        pass
    self.after(100, self.poll_queue)

这套模式里，消息队列是关键。它能避免线程之间直接改控件的脏数据竞争，也让界面单次轮询时一次性处理完队列里的所有待消费消息，不会积压延迟。要注意 queue.Empty 的判断和 after 重新注册的位置，防手滑把一个超长循环写成无限循环挂在 after(0) 上面，导致 CPU 空转。

5.3 大批量写入不要用逐条 commit，批次提交会让时长少一个量级

同样是导入 5 万行商品资料，如果你用之前那种每条 insert 后立刻 commit 的方式，时间能在几十秒到几分钟之间飘忽不定。因为每条 commit 会触发一次磁盘同步，产生大量 I/O 开销。改成攒够 500 行左右做一次批量 executemany 加一次 commit，整体耗时会大幅下降。

code复制def batch_insert(self, rows):
    sql = """
        INSERT OR REPLACE INTO products
        (product_id, product_name, category, stock, sale_price)
        VALUES (?, ?, ?, ?, ?)
    """
    batch_size = 500
    for start in range(0, len(rows), batch_size):
        batch = rows[start:start + batch_size]
        with self.db.thread_lock:
            try:
                self.db.conn.executemany(sql, batch)
                self.db.conn.commit()
            except sqlite3.Error:
                self.db.conn.rollback()
                raise

这种写法并不会牺牲事务安全性，因为你依然保证了一个批次内的数据要么全部写入成功、要么全部回滚。真正要避免的是把几万条数据裹在一个巨型事务里，因为一旦中途失败，回滚成本和锁持有时间都会让系统雪上加霜。

6. 写库时的细节坑位盘点：时间字段、默认值、大小写匹配

6.1 时间字段别在 Python 里手动拼字符串，交给 SQLite 统一生成

表格设计时，我给很多业务表加了 created_at 和 updated_at 字段。最初的写法是在 Python 代码里 datetime.now() 手动格式化后拼进 SQL 参数，后来遇到一个情景：客户端电脑的本地时间被改错了，导致所有新单据的时间戳乱套。从那以后，我的策略是：默认值交给 SQLite 生成，只在特殊情况下才由业务层显式传时间。

code复制CREATE TABLE stock_records (
    record_id TEXT PRIMARY KEY,
    product_id TEXT NOT NULL,
    type TEXT CHECK(type IN ('in', 'out', 'adjust')),
    quantity INTEGER NOT NULL,
    remark TEXT,
    created_at TIMESTAMP DEFAULT (datetime('now', 'localtime'))
);

把 datetime('now', 'localtime') 写进建表语句，既能保证时间格式统一，也能顺带把时区转换放在数据库侧完成。不过要注意，SQLite 的时间函数生成的格式是 YYYY-MM-DD HH:MM:SS，恰好能被大多数 Python 库直接解析为字符串比较的格式，排序时用 ORDER BY created_at DESC 也自然正确。

6.2 值为空和空字符串是两回事，别混为一谈

早期做表单时，“没填”和“填空字符”经常被我一股脑看成同一件事，于是存进数据库的数据里既有 NULL 又有 ''。等写查询时才发现灾难：你对某个字段做 LIKE '%' 时，NULL 不会匹配；你统计非空数量时，NULL 和 '' 的过滤条件又不一样。

我现在给出的硬性约定如下：

• 字符串型可选字段，如果没有任何内容，一律写入空字符串；
• 数值型可选字段，如果没有任何内容，一律写入 0 而不是 NULL，除非这个字段的语义明确是“未知”；
• 只有像“删除时间”“审核时间”这类表达“事件还没发生”的时间字段，才允许使用 NULL。

这样规则统一后，DAO 层不用每次查询都写 WHERE COALESCE(remark, '') != '' 这种丑陋的条件。界面层取值时也可以用 if row.get("remark") 直接判断是否为空字符串，逻辑一眼就懂。

6.3 SQLite 的字段类型宽容不等于你可以乱来

SQLite 有一个容易被误解的点：它支持 INTEGER、TEXT、REAL 等类型，但它本质是动态类型系统。如果一个列声明为 INTEGER，你往里插入字符串 "abc" 时它通常不会报错，而是原样保存。这个特性在开发期能容忍你的粗心，但对一个需要长期运行的系统来说，这是致命伤。

为了把问题在第一时间暴露出来，我在项目里加了一个防御措施：DAO 层方法在写入关键数值字段前，显式做一次类型转换。比如 int(quantity)、float(sale_price)，如果不能转换就直接抛出明确的 ValueError，并附带“商品编号 xxx 的库存数量格式错误”这样的提示，而不是让脏数据悄悄落库。

同时，我建议你尽可能在数据库层面加约束，比如 CHECK(quantity >= 0)、CHECK(sale_price >= 0)。这些约束在你手动打开数据库、或者以后写了其他入口时，仍然能起保护作用，不会因为你换了调用途径就失效。

7. 从单机到局域网共享：数据库文件放哪、怎么锁、怎么备份

7.1 数据库文件路径的三个候选位置，我最后选了用户数据目录

数据库文件存放位置是项目管理里最容易被忽略但影响巨大的决策。很多人图省事直接写死成 data.db，放在程序当前工作目录。这在开发机上没问题，但当你用 PyInstaller 打包后，双击程序启动时的工作目录未必是程序所在的文件夹，可能被系统设成用户目录、桌面或安装工具临时目录；一旦程序因为权限不足无法写文件，应用就会连启动都失败。

我推荐按系统区分选择目录：

• Windows 下用 %APPDATA%/你的产品名/data.db；
• Linux/macOS 下用 ~/.local/share/你的产品名/data.db。

这需要你提前 ensure_dir_exists() 创建目录，不要等 sqlite3.connect 报“unable to open database file”才找问题。如果做的是绿色便携版、希望数据文件跟着程序目录移动，那也没问题，但要明确告诉使用者“文件夹不能放在需要管理员权限的 Program Files 下”，否则普通用户写入数据会失败。

code复制def get_db_path(app_name="DataManager"):
    if sys.platform == "win32":
        base_dir = os.environ.get("APPDATA") or os.path.expanduser("~")
    else:
        base_dir = os.environ.get("XDG_DATA_HOME") or os.path.expanduser("~/.local/share")
    db_dir = os.path.join(base_dir, app_name)
    os.makedirs(db_dir, exist_ok=True)
    return os.path.join(db_dir, "system.db")

7.2 局域网多机共用一个 SQLite 文件：能用但有前提

既然是“企业级”场景，很多时候不止一台电脑在操作。让多台机器通过共享文件夹直接指向同一个 SQLite 文件是可行的，但前提是网络文件服务稳定，别用某些写缓存策略极激进的网盘同步目录。SQLite 官方文档也明确提醒过：不要将数据库放在 NFS、SMB 等网络文件系统上长期使用，因为文件锁机制可能不可靠，尤其在 Windows 的 SMB 共享下面，锁语义的缺陷会导致 database is locked 出现得特别频繁。

如果你确实是在同一办公室的几台电脑上共享一个数据库，我的方案是：换用带轻量网络接口的架构，例如用一台机器跑一个简单的 REST 接口，其他客户端通过 requests 调接口读写数据；或者干脆使用 SQLite 的服务端变体如 rqlite 等方案。受本文主题限制就不展开，但把话说在前面，能帮你避开最尴尬的故障现场。

7.3 自动备份策略：每天留一份，保留最近 10 份

即便架构再稳健，我也坚持给系统加自动备份。SQLite 备份最简单可靠的方式是使用其在线备份 API，它能在数据库被正常打开和读写的情况下生成一致性快照，而不是直接 shutil.copyfile——因为直接复制一个正在写操作中的数据库文件，可能复制到一半的事务状态。

code复制def backup_database(conn, backup_dir, max_backups=10):
    os.makedirs(backup_dir, exist_ok=True)
    timestamp = time.strftime("%Y%m%d_%H%M%S")
    backup_path = os.path.join(backup_dir, f"backup_{timestamp}.db")
    dest_conn = sqlite3.connect(backup_path)
    try:
        conn.backup(dest_conn)
    finally:
        dest_conn.close()

    backups = sorted(glob.glob(os.path.join(backup_dir, "backup_*.db")))
    if len(backups) > max_backups:
        for old_file in backups[:-max_backups]:
            os.remove(old_file)

这个备份函数建议在程序启动时、主界面关闭前、或每天定时器触发一次。它能保证即使程序今天崩溃或数据库文件被外部误删，你也能从最近一份备份里恢复接近当前的数据。

8. 交付前必须过的三道关：打包路径、日志追踪、版本迁移

8.1 PyInstaller 打包后“找不到模块或数据文件”的典型原因

开发期运行正常的代码，打成一个 exe 给同事用，结果双击报错 ModuleNotFoundError 或者找不到 icon.ico，这是几乎所有桌面项目的必经之路。根因是 PyInstaller 默认不会把你代码里动态加载的模块、非 Python 数据文件一并打包进去。

如果你的代码中出现过 __import__、动态字符串导入、或者依赖了某些通过插件机制加载的库，记得在 .spec 文件中的 hiddenimports 里显式列出来。数据库文件如果设计为首次启动自动创建，那不用打包初始库；如果预置了一些基础分类数据，那就需要把 db 文件作为 datas 加进去，并在程序首次运行时拷贝到用户数据目录。

写 .spec 时的关键配置大概是：

code复制a = Analysis(["main.py"], hiddenimports=["你的动态导入库"], datas=[("assets/icon.ico", "assets")], ...)
exe = EXE(...)

还有一个细节：如果你的系统用到了 ttk 主题、自定义字体等资源，注意打包后路径中不要出现中文或空格路径导致资源加载失败。尽量让输出的 exe 放在一个纯英文路径下再做测试。

8.2 日志别只靠 print，写文件才是排障的底气

桌面应用最怕的是“跑着跑着数据不对，还没处说理”。没有日志，用户只能给你描述症状，你猜破头也不知道他当时点了哪个按钮、数据库处在什么状态。我给系统中每个关键业务操作都埋了日志，包括登录、新增、删除、导入等动作，以及发生异常时的堆栈。

一般用 Python 标准库的 logging 即可，设置一个好的格式、按天滚动文件，别把日志文件也塞进程序安装目录，而是放到和数据库同一个用户数据目录下：

code复制import logging

def setup_logging(log_dir):
    log_file = os.path.join(log_dir, "app.log")
    handler = logging.FileHandler(log_file, encoding="utf-8")
    handler.setFormatter(logging.Formatter(
        "%(asctime)s [%(levelname)s] %(name)s: %(message)s"
    ))
    root_logger = logging.getLogger()
    root_logger.setLevel(logging.INFO)
    root_logger.addHandler(handler)

如果数据库出现事务回滚，我习惯把回滚原因也打进日志，方便后续检查是“哪种 SQL 导致异常”。操作类和界面层里尽量少写 print，一律走 logger，这样既不会污染命令行，排查时也有完整时序。

8.3 版本迭代：表的演进需要一份迁移清单

最后，一个现实问题：你第一版只给系统了 5 张表，第二周客户就要加“采购单号”字段，第三周又要加“批次有效期”。如果直接改建表脚本，让使用者删库重来，他之前录入的数据全没了，真要摔键盘。

所以从第一版上线前，我建议你维护一个简单的数据库版本表。项目在启动时检查当前版本号，与代码内置版本号比对，需要升级时顺序执行迁移 SQL。

code复制CREATE TABLE IF NOT EXISTS db_meta (
    version INTEGER NOT NULL
);

然后在代码里维护一个 MIGRATIONS = [(1, "ALTER TABLE products ADD COLUMN batch_no TEXT;")] 的列表。每次发布新版本，就把对应的 ALTER TABLE 语句追加到列表里，启动时依次执行。这个方法虽然原始，但在小规模桌面应用里比引入 Alembic 这类迁移工具轻得多，也足够可靠。

当然，每一步迁移最好在事务里执行，并把执行结果同步写入日志；如果某条迁移语句执行失败，立刻回滚并弹窗提示用户联系你处理，绝不能让程序带着不完整的表结构继续运行。

我个人真切的经验是：桌面管理系统最先崩溃的往往不是性能，而是没有一套自己可解释的数据变化路径。把这个基础打好，后续无论是加报表、加权限、还是扩充模块，都只是沿着同样的模式继续补代码而已。如果你正准备上手或者已经在做类似项目，照着这个结构去梳理自己的代码，能省下很多深夜排错的时间。