.db 只是一个很宽泛的扩展名，并不保证文件一定是 SQLite。聊天软件、浏览器、手机应用和桌面软件都可能把自己的数据文件命名为 .db，里面既可能是标准 SQLite，也可能是加密数据库或某种私有格式。

如果只是想确认文件中有哪些表、某条记录是否存在，没必要先安装完整的数据库管理软件。SQLite 数据库查看器会在浏览器中加载数据库副本，列出表、视图、索引和字段，并允许查询后导出 CSV 或 JSON。文件不会为了分析而上传到网站服务器。

先确认它是不是 SQLite#

标准 SQLite 数据库的文件开头通常包含 SQLite format 3。扩展名可以是 .sqlite、.sqlite3、.db，也可以完全没有扩展名，所以判断格式时应看文件内容，而不是只看名称。

工具无法打开文件时，常见原因有下面几种：

  • 文件其实不是 SQLite，只是碰巧使用了 .db；
  • 数据库使用 SQLCipher 等方案加密；
  • 复制数据库时程序仍在写入，主文件、-wal 和 -shm 没有一起处理；
  • 下载或传输中途被截断；
  • 文件体积过大，当前浏览器没有足够内存。

不确定格式时，可以先用文件类型识别工具查看文件签名。生产系统的数据库不要直接从正在运行的目录里拖走，优先使用应用自带的导出功能，或先完成 SQLite checkpoint，再制作一致的备份。

打开以后先看表结构#

载入文件后，先不要急着写复杂 SQL。左侧对象列表已经能回答不少问题：

  1. 表和视图的名称是否符合预期；
  2. 每张表有哪些字段、类型、默认值和主键；
  3. 是否存在关联查询会用到的索引；
  4. 建表语句中有没有唯一约束或外键；
  5. 数据库里是否混有缓存表、日志表和真正的业务表。

点击表名可以预览前一部分数据。SQLite 的类型约束比很多服务端数据库宽松，同一字段里出现数字、文本和空值并不罕见。日期也可能保存为 ISO 文本、Unix 时间戳或整数天数，导出前要先看实际值，不能只凭字段名猜格式。

用查询缩小范围#

只看前几百行不够时，可以用 SELECT、公共表表达式和 PRAGMA 做检查。例如：

sql已剪下 ✓
SELECT status, COUNT(*) AS total
FROM orders
GROUP BY status
ORDER BY total DESC;

查找某段时间的数据时，先确认时间字段的存储方式：

sql已剪下 ✓
SELECT id, customer_id, amount, placed_at
FROM orders
WHERE placed_at >= '2026-07-01'
ORDER BY placed_at DESC
LIMIT 100;

页面每次只执行一条语句，结果最多显示 1000 行，目的是避免误粘贴一串脚本后得到难以核对的结果。数据库运行在标签页内存中，即使执行了修改语句，也不会覆盖你磁盘上的原文件；但做检查时仍建议只写 SELECT 和 PRAGMA，避免当前会话里的后续统计被临时修改影响。

CSV 和 JSON 该选哪个#

结果是二维表，准备交给 Excel、表格软件或数据分析同事时，CSV 最方便。字段里包含逗号、换行和双引号时，导出器会按 CSV 规则转义，打开后仍应确认软件识别的字符编码和日期格式。

JSON 更适合保留空值和字段名称，也方便继续交给脚本处理。SQLite 的 BLOB 不是普通文本：CSV 中会显示长度和一小段十六进制预览，JSON 中则会记录字节数和十六进制内容。体积较大的图片或附件不适合通过查询结果整批转成 JSON。

如果下一步要整理列名、去重或筛选，可以把 CSV 交给CSV 筛选与排序工具继续处理。

这类在线查看器不能代替什么#

浏览器查看器适合临时检查、数据核对和小范围导出，不适合修复损坏数据库、恢复已删除记录、合并 WAL、执行长期迁移或分析超大型文件。它也无法替你判断一张陌生表是否包含个人信息。

处理客户、订单、聊天记录和登录数据时，即使文件只在本地浏览器里读取，也应使用自己的可信设备，操作结束后关闭标签页，并妥善删除导出的副本。需要长期维护数据库时，再使用 SQLite CLI、DB Browser for SQLite 或正式的数据迁移脚本。

总结#

打开陌生 DB 文件的合理顺序是：先确认格式，再看对象和字段，随后用小范围查询验证，最后只导出真正需要的数据。

SQLite 看起来只是一个文件，实际内容可能包含一个应用的大部分状态。先理解结构再动数据，比一上来把整库转成 Excel 更稳妥，也更容易发现复制不完整、时间格式异常和字段含义不清这些真正的问题。