当前位置：首页 > news >正文

抓包历史为什么从 sql.js 迁到原生 SQLite

news 2026/8/9 3:09:21

原文出处：本文首发于 DevPeek 官网博客
原文链接：https://devpeek.ypgao.com/blog/dev-build-log-sqljs-to-better-sqlite3/
作者：DevPeek 团队
转载说明：欢迎转载，请注明出处并保留原文链接。

DevPeek 是面向联调的抓包与 Mock 工具。从 v1.1.4 起，抓包记录会写到本地，重启应用也能看近期历史；脚本改过的请求头、响应体也会一并保存。后来协作消息、调试页里的 Network 记录、重发历史，也都需要长期留着。

这篇开发实录想讲清楚一件事：我们为什么把抓包历史的存储，从跑在 JavaScript 里的 sql.js，换成操作系统级的原生 SQLite。

我们遇到的坑：代理挂久了，人比电脑先扛不住

DevPeek 不是「抓几个包就关」的工具。很多人会让代理开着，手机或 WebView 一直走流量，列表里堆几千条请求，调试页还要翻上午抓过的包。

一开始，我们选了sql.js——一种常见于网页里做本地存储的纯 JavaScript 版 SQLite。接入快、不依赖系统原生组件，早期功能少的时候够用。

联调场景一忙起来，坑就暴露了。

现象：越抓越沉，像「该重启了」

如果你用 DevPeek 时遇到过下面几种情况，很可能就是同一类问题：

代理从上午开到傍晚，电脑越来越卡，任务管理器里 DevPeek 占的内存慢慢往上走。
列表里请求一多，翻页、搜索、点详情偶尔顿一下；Mock、断点还在跑，整机像被拖住。
心里默认「联调结束关一下就好」——工具本该在后台默默干活，却像挂久了就得重启。

根因在我们这边：sql.js 把整库放在内存里。每来一条抓包、每改一次请求详情，我们都要把越堆越大的整份数据库拷贝一遍再写回磁盘——相当于每隔一小段时间，把越堆越厚的笔记本从头到尾复印一次。

抓包越多、每条请求的 Header/Body 越大，复印就越慢、内存峰值越高。代理同时还要解密 HTTPS、跑 Mock、拦断点，卡顿就叠在一起了。

列表看起来能分页、能筛选，但底层仍是「内存里攒一大坨、周期性整库落盘」——和「直接往硬盘上的数据库文件里追加一条」不是一回事。功能继续加（参数转换、页面调试、协作同步）之后，这不是小优化能抹平的，而是存储方式选错了。

我们怎么改的：换成原生 SQLite，为「挂一整天」

我们一次性把抓包、协作等存储，从 sql.js迁到原生 SQLite——就是操作系统里那种真正的本地数据库，DevPeek 通过原生模块直接读写磁盘上的文件。

动机很单纯：性能和内存。希望 DevPeek 可以连续跑一整天，内存也完全没压力。

改完以后，写入方式变了：

以前（sql.js）	现在（原生 SQLite）
数据主要在哪	内存里越堆越大	在本地数据库文件里
怎么保存	隔一会儿整库拷贝写盘	来一条记一条，改哪里写哪里
挂一整天	内存容易往上走，偶尔卡	内存曲线平稳，列表跟手

改完以后，代理开着跑一天，列表照常翻、Mock 照点，不用为了「怕卡」而习惯性重启 DevPeek。

工程上，原生组件打包、发版会多费些事——我们愿意付这个成本，因为 DevPeek 的定位就是长时间陪联调，不能在存储层掉链子。