写这个工具的时候，我其实是被一个重复到让人崩溃的场景逼出来的：明明只是想在 SQLite 里看几张表、改几条记录，却得打开一个笨重的通用数据库客户端，连接字符串配半天，界面把几十个用不上的表全列出来，想查一条数据还得手工写 SQL。用命令行工具又不直观，敲完SELECT按回车，出来的是一堆没有表格线的原始文本。对不常写 SQL 的人来说，这种体验几乎等于劝退。
于是我用 Python 自带的 tkinter 和 sqlite3 标准库，花了几个晚上写了一个 SQLite 数据库可视化小工具。它不追求功能全面，只求一件事：双击打开、选表、看数据、直接改。这篇文章会把我从零到能用的完整思路和实现细节记录下来，包括界面骨架怎么搭、数据库层怎么封装、树的刷新为什么总有坑、以及 CSV 导出和 SQL 执行面板该怎么做取舍。如果你也想给某个内部数据文件做一套轻量维护界面，或者想用 tkinter 练习桌面工具开发，那这篇文章可以直接当参考代码来用。
1. 先回答一个问题：为什么还要自己写一个 SQLite 可视化工具
市面上已经有不少现成的 SQLite 图形工具，功能很齐全，能看表结构、能跑 SQL、能画 ER 图。那我为什么还要自己写？原因主要是以下三个场景叠加出来的。
第一，我需要的是一个能被 Python 程序内嵌的界面。很多时候，SQLite 数据库只是整个桌面流程里的一个中间产物，比如某离线数据采集程序把结果写进data.db，下一步希望有一个窗口让使用人员直接查看和修正。这时候再去安装一个外部工具就割裂了，最顺手的方案是把界面直接打包进 Python 程序里，点一个按钮就打开。第二，现成的通用工具大多默认你是懂 SQL 的，它们的界面重心放在查询编辑器上，而我需要的是那种“选中表、双击改值”的操作方式，让不懂 SQL 的同事也能上手。第三，tkinter 是 Python 自带的 GUI 库，不用额外装任何第三方依赖，打包体积也小，一个库文件加一个.py脚本就能分发，这对内部小工具来说非常友好。
当然，tkinter 确实不是最好看的框架，控件风格偏朴素，但它在“快速开发”这件事上的优势非常明显：ttk.Treeview几乎是现成的表格控件，配合sqlite3标准库，不需要引入重型 ORM，也不用前后端分离——单文件就能搞定。如果你只是需要一个内部维护数据的工具，这种组合是最省事的。
我的建议是，先别急着写界面，先把数据库访问层单独封装起来。这个阶段很多人会犯一个错误：直接在按钮回调里写sqlite3.connect()，然后到处拼 SQL，最后代码变成一锅粥。可视化工具的逻辑其实很简单，但简单不等于可以没有结构。我通常把代码分成三个层次：数据库连接层、界面层、操作回调层，每一层只负责一件事，后续要加功能，改起来也不至于牵一发动全身。
2. 搭地基：界面骨架和数据库连接层如何分工
我这里虽然把“数据库连接”“界面”分开说，但它们的关系很紧密。整个工具运行时会经历三个阶段：打开数据库文件，读取表名列表；点击某个表，读取该表的结构和数据；在表格里选中一行，通过表单或右键菜单增删改。搞清楚这个流程之后，界面布局和函数拆分就都清楚了。
2.1 先做一个不会被锁死的数据库连接封装
SQLite 有个特点：它本质上是单文件数据库，读写的锁机制和 MySQL 这种服务型数据库完全不同。如果每次操作都新建连接，写完后不关闭，文件会被一直占用，后续写入会报database is locked。如果全程共用一条连接，界面线程里又要在多个回调里反复执行复杂操作，偶尔也会遇到“attempt to write a readonly database”这类让人摸不着头脑的错误。
我自己采用的方案是一个简单的DbHandler类，类内部负责连接的创建和基础操作方法。关键点是统一设置row_factory，让查询结果可以通过列名访问，这对后面动态生成界面非常有帮助。
import sqlite3 class DbHandler: def __init__(self, db_path): self.conn = sqlite3.connect(db_path) self.conn.row_factory = sqlite3.Row self.conn.execute("PRAGMA foreign_keys = ON") def get_tables(self): cur = self.conn.execute( "SELECT name FROM sqlite_master " "WHERE type='table' AND name NOT LIKE 'sqlite_%' " "ORDER BY name" ) return [row["name"] for row in cur.fetchall()] def get_columns(self, table): cur = self.conn.execute(f'PRAGMA table_info("{table}")') return cur.fetchall() def get_count(self, table): cur = self.conn.execute(f'SELECT COUNT(*) AS cnt FROM "{table}"') return cur.fetchone()["cnt"] def close(self): self.conn.close()说两个容易被忽略的设计点。一个是排除sqlite_%开头的内部表，否则列表里会混进一堆系统表，界面很乱。另一个是表名和列名的拼接一定要用双引号包裹，因为 SQLite 对标识符的转义规则和字符串不一样，遇到表名里带空格或者中文的情况，不加双引号直接报语法错误。表名来自用户选择的列表项，属于程序内部可控数据，但养成这种习惯可以避免很多无谓的坑。
2.2 主窗口布局：三块区域怎么安排
主界面的布局我没有用复杂的网格嵌套，而是选了一个横向的PanedWindow，左边放表列表，右边放数据展示和操作面板。整个窗口结构大致是：
- 顶部工具栏：打开数据库、刷新、执行 SQL、导出 CSV 几个按钮。
- 左侧：
ttk.Treeview只显示一列，展示所有用户表。 - 右侧：上方是一个纵向滚动且支持多列排序的表格，下方是当前选中行的字段明细和增删改按钮。
为什么不用绝对定位？因为数据库表可能很多，列也可能很多，窗口在运行时要能随意拉伸，Grid 布局在列数变化时要算权重，很容易顾此失彼。树控件和表格控件天然带滚动条和列宽调节能力，用 pack 配合 PanedWindow 反而是最稳的。
from tkinter import ttk, filedialog, messagebox import tkinter as tk class SqliteViewer(tk.Tk): def __init__(self): super().__init__() self.title("SQLite 可视化小工具") self.geometry("980x640") self.db = None self.current_table = None self._build_ui() def _build_ui(self): top = ttk.Frame(self) top.pack(fill="x", padx=8, pady=6) ttk.Button(top, text="打开数据库", command=self.open_db).pack(side="left") ttk.Button(top, text="刷新", command=self.refresh_tables).pack(side="left", padx=6) ttk.Button(top, text="SQL 执行面板", command=self.show_sql_panel).pack(side="left") ttk.Button(top, text="导出 CSV", command=self.export_csv).pack(side="left", padx=6) paned = ttk.PanedWindow(self, orient="horizontal") paned.pack(fill="both", expand=True, padx=8, pady=6) left = ttk.Frame(paned) self.table_list = ttk.Treeview(left, show="tree", height=20) self.table_list.pack(fill="both", expand=True) self.table_list.bind("<<TreeviewSelect>>", self.on_select_table) paned.add(left, weight=1) right = ttk.Frame(paned) columns = ("cid", "name", "type") self.data_tree = ttk.Treeview(right, show="headings", columns=columns) vsb = ttk.Scrollbar(right, orient="vertical", command=self.data_tree.yview) self.data_tree.configure(yscrollcommand=vsb.set) self.data_tree.pack(fill="both", expand=True, side="left") vsb.pack(fill="y", side="right") paned.add(right, weight=3)界面骨架跑通之后，下一步才是真正头疼的部分：把一个数据库表的结构翻译成界面上能看懂的东西。
3. 表结构感知与数据读取：把“数据”变成“界面能懂的东西”
可视化工具的核心是把数据库表变成表格显示。但数据库表和界面上显示的表格之间，隔着一层“表结构感知”逻辑。直接SELECT *当然可以拿到数据，但列名、列类型、主键、可否为 NULL 这些元数据，才是决定界面如何展示的关键。
3.1 用 PRAGMA 而不是 sqlite_master 拿字段信息
SQLite 的PRAGMA table_info(表名)会返回每一列的详细信息，包括字段序号cid、字段名name、字段类型type、是否非空notnull、默认值dflt_value、是否主键pk。这个信息比直接从sqlite_master里解析建表 SQL 要可靠得多。
有人会问，为什么不直接把sqlite_master里的 SQL 文本拿过来正则解析？因为 SQLite 的建表语法兼容性很好，但一个表可以由多个子句组成，还有可能带WITHOUT ROWID之类的特殊选项，靠正则解析边界情况太多。PRAGMA table_info是 SQLite 官方提供的标准化接口，跨版本稳定，遇到带引号或特殊字符的列名也没问题，我建议一律用它。
拿到字段列表后，还要做一件事：判断这张表能不能安全地进行行级更新。SQLite 几乎每张表都有一个隐式的rowid，但如果建表时指定了WITHOUT ROWID或者用INTEGER PRIMARY KEY当主键，行为会有区别。我用一个简单规则判断：如果字段列表里存在pk=1的列，不管它是自增主键还是复合主键的一部分，统一用所有主键列作为定位条件；如果没有主键，就回退到rowid，这也意味着这张表只适合只读浏览，删除和修改要谨慎处理。
def on_select_table(self, event): sel = self.table_list.selection() if not sel: return table = self.table_list.item(sel[0])["text"] self.current_table = table cols = self.db.get_columns(table) self.columns_info = cols self.load_data(table, cols) def load_data(self, table, cols): self.data_tree.delete(*self.data_tree.get_children()) self.data_tree["columns"] = [c["name"] for c in cols] headings = [] for c in cols: headings.append((c["name"], c["type"])) self.data_tree["show"] = "headings" for idx, c in enumerate(cols): self.data_tree.heading(c["name"], text=f'{c["name"]} ({c["type"]})') self.data_tree.column(c["name"], width=120, anchor="w") rows = self.db.fetch_page(table, self.page_size, self.page_offset) for row in rows: self.data_tree.insert("", "end", values=[row[c["name"]] for c in cols])这里有一个动态列名和Treeview配置的细节：Treeview在columns里使用列名作为内部标识，列名的字符串本身会被当成控件配置的一部分。所以列名里如果出现空格、中文、特殊符号，直接传给heading一般没问题，但传给column的width参数时要小心。我习惯把列名包装成col_0、col_1这样的内部标识，再单独保存一份列名到显示文本的映射，这样最干净，也不容易出乱子。
3.2 不能把全表数据一口气塞进表格
第一次做这工具的时候，我直接SELECT * FROM 表名，然后把所有行插入Treeview。数据量小的时候没问题，一旦表里有几万行，界面会在插入过程中卡死，鼠标拖动滚动条都费劲。后来我把数据加载改成了分页模式：显示多少行，就向数据库只查多少行。
分页的实现不复杂，可以用LIMIT ? OFFSET ?取当前页，用一个COUNT(*)拿总行数，界面上再加“上一页”“下一页”两个按钮。不要贪心一次加载太多，一个页面我固定成 500 行，对多数内部工具来说已经是上限了。
def fetch_page(self, table, limit, offset): sql = f'SELECT * FROM "{table}" LIMIT ? OFFSET ?' cur = self.conn.execute(sql, (limit, offset)) return [dict(row) for row in cur.fetchall()]这里把每行的sqlite3.Row转成dict，是因为Treeview的values参数只接受可迭代的元组或列表，而Row对象虽然也能迭代，但转成dict之后后续取某个字段、做值修改都会方便很多。
3.3 类型显示：None、BLOB、日期到底怎么处理
这是可视化工具里最容易让新手头疼的一部分。SQLite 是弱类型数据库，TEXT 列里可能塞着数字，整数列里也可能存了 NULL。程序在显示层必须统一处理几种特殊值：
None：如果直接塞给Treeview，会显示成一个空字符串，看起来像是“有数据但没写”，容易误导用户。我更愿意显示成醒目的NULL文本，提醒用户这个字段确实没有值。- BLOB 类型：二进制数据不能直接转字符串，否则会遇到编码错误。在表格里显示成
<BLOB: 128 bytes>这类摘要，详情之后再通过表单查看。 - 时间类型：SQLite 没有专门的时间类型，很多程序会把时间存成 ISO 格式字符串。这本来不值得处理，但如果有人存的是浮点数时间戳，界面上显示一长串数字就很难读。我在显示层加了一个轻量判断：字段名里包含
time或date，且值是整数或浮点数，就尝试转成YYYY-MM-DD HH:MM:SS的格式，转换失败就保持原样。
这套显示规则看起来很基础，但实际做出来后，工具的“能看懂”程度提升了一个档次。很多人说自己的工具“能用”，其实只是把数据原样丢给控件，用户面对一堆None和二进制乱码，根本不知道发生了什么。
4. 增删改查与表单生成：把 SQL 手写感降到零
当表格能正常显示之后，下一个需求自然就来了：点一个按钮就能改数据。这个环节的设计直接决定工具是不是真的好用。SQL 当然能写，但一个可视化工具如果改一行数据还要手工敲UPDATE，那它跟命令行就没有区别了。
4.1 行级操作：选中哪行，工具要知道主键在哪
我做的方案是这样的：在数据表格下方放一行按钮，选中一行后，“编辑选中行”按钮变成可用状态。点击编辑，弹出一个新窗口，按照当前表的字段顺序生成表单控件。
关键问题在于，程序如何识别“选中了数据表中的哪一原始行”。Treeview的选中项只是界面上的一个虚拟节点，数据从数据库读出来后已经不存在一一对应的引用关系。我的做法是把每一行的主键值一起存入节点中，用iid保存主键的拼接结果。拼接规则必须可靠，不能简单用逗号拼，因为主键值本身可能含逗号。更稳妥的做法是使用一个自定义的分隔符，或者干脆用 JSON 序列化保存主键值列表。
def get_primary_key_values(self, item): pk_indexes = [c["cid"] for c in self.columns_info if c["pk"]] if not pk_indexes: return None, [] # 没有主键，需要提示用户 values = self.data_tree.item(item)["values"] pk_values = [] for idx in pk_indexes: raw = values[idx] pk_values.append(self.deserialize_literal(raw)) return pk_indexes, pk_values这里有一个很容易踩的坑：界面上显示的是NULL文本或格式化后的时间字符串，但把它当作 WHERE 条件的值写进 SQL 时，必须还原成数据库里的原始值。我前面在显示层做“格式化”的时候，一定会在同一行的底层数据里保留原始值。这里我选择了一个取巧的做法：在Treeview的values里放的是原始值，但显示文本通过Treeview的tag或单独维护的字典来格式化。如果只是简单粗暴地在values里放格式化后的字符串，更新、删除时就会根据显示文本去数据库里找记录，几乎必然失败。
4.2 动态表单窗口：根据字段类型生成控件
编辑窗口里的空间控件，我会根据字段类型做差异化处理：
- 整数和实数类型：用
ttk.Entry，但会绑定一个validatecommand，只允许输入数字。 - TEXT 类型：默认用
ttk.Entry；如果字段名包含content、body、remark，内容可能很长，就用tk.Text多行控件，高度设成 6 行。 - 主键字段默认只读，不允许用户随意修改主键，防止把数据改乱。
表单生成的核心逻辑其实就是根据PRAGMA table_info的结果，构建一个字段控件列表。这块不用写得多复杂，但需要遵守一个规则：控件控件创建时，用grid一行一个字段，左侧 Label 显示字段名，右侧放输入控件。把字段名和原值存到一个字典里，等用户点“保存”时再统一取出来做类型转换和 SQL 更新。
4.3 数据校验与事务回滚：不要一错就整张表报废
写更新代码的时候，我吃过一次亏。某次更新脚本里直接把界面的字符串拼进 SQL，结果用户在一个整数列里输入了一个非数字，程序报错，连接的事务留下了脏数据。更严重的是，那一次更新是一整批循环执行的，前几条更新成功，后面某条失败，数据就处于半新半旧的尴尬状态。
所以后来我在DbHandler里统一包装了事务操作：从界面上拿到所有字段值后，先逐字段做类型转换和合法性检查，任何一个字段不合格，直接在界面弹提示，不执行 SQL；全部通过后，用executemany或单条execute执行，执行结束后调用commit()，如果捕获到异常就rollback()，同时把错误细节弹出来。
def update_row(self, table, pk_cols, pk_vals, field_names, field_vals): set_clause = ", ".join([f'"{name}" = ?' for name in field_names]) where_clause = " AND ".join([f'"{col}" = ?' for col in pk_cols]) sql = f'UPDATE "{table}" SET {set_clause} WHERE {where_clause}' try: self.conn.execute(sql, field_vals + pk_vals) self.conn.commit() except Exception as e: self.conn.rollback() raise e注意field_vals + pk_vals的顺序必须和set_clause + where_clause里的问号顺序完全一致。我在初版代码里就栽过这个跟头，问号数量和参数数量对不上，界面每次保存都报Incorrect number of bindings supplied。这个错误本质是拼 SQL 的时候占位符和参数顺序不同步，没有别的技巧，只能靠仔细，或者把 SQL 拆成多行，用注释标明哪个问号对应哪个字段，调试起来会快很多。
5. 我在实际开发中踩过的坑：刷新、编码和主键识别
可视化工具看起来不难，但真正把它写到“能稳定给人用”，中间那几个隐藏的坑比想象中多。这里的每一个问题都是我实际调试过程中撞出来的，分享出来能帮你少走很多弯路。
5.1 Treeview 刷新导致滚动条位置丢失
每次刷新数据我都是先delete所有子节点，再重新插入新数据。因为数据表里用了分页，用户翻到第三页，点击刷新后，界面会直接回到第一页，滚动条位置也重置了。这个问题初看不严重，但实际使用中会非常烦人——用户改了某一行数据，希望刷新后还能看到当前页，但界面跳到第一页，他得重新翻好几页回去。
解决方案是在刷新之前记录当前页面偏移量，然后只刷新当前页的数据，而不是重置为第一页。如果当前页恰好是最后一页，删掉了若干行后总页数可能变化，那就要判断offset是否超过新的总行数，超过则回退到最后一页。这个处理逻辑就是几行代码的事，但很多人写动态表格时不会考虑，等到被同事吐槽“怎么刷新一下白翻了”之后才想起来。
5.2 中文字符和编码问题在 tkinter 里是被问得最多的
tkinter 在 Python 3 里默认使用 Unicode，字符串显示中文一般没有大问题。真正的麻烦来自两个地方：第一，数据库文件里的编码不是utf-8，常见的老旧系统使用gbk编码写入的 TEXT；第二，用户在界面里输入内容，保存后乱码。
处理思路并不复杂：sqlite3读出来的字符串已经是 Python 的str对象，本身没有编码问题，关键在于写入数据库时，SQLite 只接受str或bytes。如果原始数据是其他编码，得在读取时用decode显式转成str，再写入就是正常的。真正容易出乱码的，反而是从 CSV 导入或从命令行sqlite3工具读取的场景，因为命令行工具有时候会用系统默认编码显示。我在这类工具里很少写数据，只负责展示，所以碰到这个问题的概率低一些。但只要涉及导出，就要统一在导出函数里声明编码为utf-8-sig，这样用 Excel 打开 CSV 时不会出现中文乱码。
5.3 主键识别的边界：复合主键和 WITHOUT ROWID 表
前面提过主键判断，但这里要专门展开。SQLite 中主键的判断方式和普通关系型数据库略有不同：如果某列是INTEGER PRIMARY KEY，它同时就是rowid的别名；如果是TEXT PRIMARY KEY，它只是一个唯一性约束，不是rowid。这带来一个结果：用rowid作为 WHERE 条件去更新，和用TEXT PRIMARY KEY作为 WHERE 条件去更新，在绝大多数情况下等价，但遇到复合主键时逻辑就不一样了。
我建议的工具策略是：优先查PRAGMA table_info里的pk字段值，把所有pk > 0的列按cid排序，作为后续更新删除的定位列。如果所有列的pk都是 0，再回退查PRAGMA index_list(表名)看有没有唯一索引，如果有就尝试用唯一索引列定位。这些信息都拿不到时，删除按钮置灰，只允许浏览和插入，避免误操作。
这种“宁可功能少一点，也不冒险破坏数据”的取舍，我认为是对的。可视化工具的第一目标永远是不要让数据变得更糟。
5.4 数据库被锁：多窗口操作与长事务
还有一个常见坑：插入或修改大量数据时，事务没提交，连接一直持有写锁，此时用户再去另一个窗口用别的工具打开同一个数据库文件，就会看到“database is locked”。我在工具界面上增加了“当前连接状态”的提示，只要执行过写操作没有commit，状态栏就显示“未提交事务”。
另外一个跟此相关的坑是：某些场景下，有人在回调里直接执行了一个SELECT COUNT(*)，但因为之前某个UPDATE异常没处理，连接事务已经处于挂起状态，这条 SELECT 竟然会被阻塞。解决方式就是严格遵循commit/rollback二选一的规则，除了只读查询外，所有写操作都必须包在显式事务里。不要依赖sqlite3默认的隐式事务行为，写操作多起来很容易被它“自动开启事务但不自动提交”的机制坑到。
6. SQL 执行面板和 CSV 导出：给工具补上最后两块拼图
数据浏览和编辑是核心功能，但一个“看起来像个正经工具”的程序，还得解决两个高频需求：临时执行自定义 SQL 和把结果导出给其他人用。
6.1 原生 SQL 执行面板：只读与写操作分开
我在主界面工具栏里放了一个“SQL 执行面板”按钮，点击后弹出一个带多行文本框的窗口。这个面板功能上对应一个精简的命令行，但界面友好得多：上半部分是输入区，下半部分是结果区，结果直接用Treeview呈现。
安全设计这里要讲清楚：执行按钮我分成两个，一个是“执行查询”，一个是“执行写入”。执行查询时，程序会检查sql语句开头是不是SELECT或PRAGMA或EXPLAIN，不是就不执行，直接提示“请使用执行写入按钮”。执行写入时，强制调用者确认“确定执行该写入语句？”，并且执行完立刻commit。这种设计不是为了防黑客——一个桌面工具本来就信任使用它的人，而是为了防止手滑敲错DELETE FROM这种不可逆操作。
def execute_custom_sql(self): sql = self.sql_input.get("1.0", "end-1c").strip() if not sql: return if sql.lower().startswith(("select", "pragma", "explain")): cur = self.db.conn.execute(sql) rows = cur.fetchall() self.show_result_as_table(rows, cur.description) else: if not messagebox.askyesno("确认", "确定执行非查询语句？"): return with self.db.conn: cur = self.db.conn.execute(sql) messagebox.showinfo("执行完成", f"受影响行数: {cur.rowcount}")关于cur.description，这里补充一个小知识点：它返回的是查询结果集的列描述信息，包含了列名和类型。用它动态生成结果表格时，可以免去硬编码列名，这样SELECT COUNT(*) FROM t或者多表 JOIN 的结果都能正常显示。
注意：使用with self.db.conn:实际上只在正常执行时提交，异常时自动回滚，这比手动写try/except/commit/rollback少几行代码，但有个副作用：with块里self.db.conn的commit行为依赖 Python 的sqlite3对上下文管理协议的支持，所以它并不适用于需要把连接交给多个界面回调共用的场景。我这里只在单次面板执行里这么用，主工具的写操作还是手动管事务。
6.2 导出 CSV：使用 utf-8-sig 编码和小数点问题
导出功能看似简单，但有两个细节值得反复强调。一个是编码：CSV 文件默认在很多 Windows 系统上打开会按 GBK 猜测编码，如果你的内容是中文，直接存成utf-8会让 Excel 打开乱码。标准做法是写文件时使用utf-8-sig，也就是带 BOM 的 UTF-8，这样 Excel 能自动识别。
另一个是数值类型：SQLite 会把数字存成 INTEGER 或 REAL，但查出来的 Python 对象可能混有float和int，写入 CSV 时如果遇到浮点数，默认的str()会带比较长的尾数，比如3.0999999999999996。这其实是二进制浮点表示带来的问题，解决方式是导出前对浮点数做格式化，保留合理位数，或者在读取阶段用round()做一次修正。对内部工具来说，把每个浮点数格式化成str(round(x, 6))就够了。
6.3 这个工具还能怎么扩展
目前这个版本已经能在完全离线的情况下满足“浏览、查询、增删改、导出”这几个基本需求。如果后续要继续增强，我想到的几个方向是：支持跨表外键跳转（点击某个关联字段，跳到另一张表）；支持搜索过滤，在表名上方加一个关键字输入框；支持直接把 Excel 粘贴进表格，实现批量导入；以及把界面样式做成深色主题，用ttk.Style统一控件风格。
不过我个人始终认为，内部工具的第一优先级是稳定和直接。与其加一堆看起来花哨的功能，不如把“打开库文件、看表、改数据、导出结果”这几条主路径打磨到极致。很多功能看着简单，加完之后维护成本却是隐形的，一旦工具变成半个复杂系统，又回到最初的痛点。
最后分享一个我后来添加的小细节：在状态栏显示“当前表：xxx | 共 N 条 | 当前第 k 页”。这样用户一眼就能知道自己在哪个表、看了多少数据，不用再刻意去数行数。这种不显眼的小功能，往往比一个大而全的菜单更能提升日常使用体验。
