开发实录
抓包历史为什么从 sql.js 迁到原生 SQLite
我们遇到的坑：代理挂久了，人比电脑先扛不住
DevPeek 是联调工具，不是「抓几个包就关」。很多人会让代理开着，手机或 WebView 一直走流量，列表里堆几千条请求，调试页还要翻上午抓过的包。
从 v1.1.4 起，抓包记录会写到本地，重启应用也能看近期历史；脚本改过的请求头、响应体也会一并保存。后来协作消息、调试页里的 Network 记录、重发历史，也都需要长期留着。
一开始，我们选了一种跑在 JavaScript 里的 SQLite（叫 sql.js，常见于网页里做本地存储）。接入快、不依赖系统原生组件，早期功能少的时候够用。
联调场景一忙起来，坑就暴露了。
现象：越抓越沉，像「该重启了」
你自己用 DevPeek 时，如果遇到过下面几种情况，很可能就是同一类问题：
- 代理从上午开到傍晚，电脑越来越卡，任务管理器里 DevPeek 占的内存慢慢往上走。
- 列表里请求一多，翻页、搜索、点详情偶尔顿一下；Mock、断点还在跑，整机像被拖住。
- 心里默认「联调结束关一下就好」——工具本该在后台默默干活，却像挂久了就得重启。
根因在我们这边：sql.js 把整库放在内存里。每来一条抓包、每改一次请求详情，我们都要把越堆越大的整份数据库拷贝一遍再写回磁盘——相当于每隔一小段时间，把越堆越厚的笔记本从头到尾复印一次。
抓包越多、每条请求的 Header/Body 越大，复印就越慢、内存峰值越高。代理同时还要解密 HTTPS、跑 Mock、拦断点，卡顿就叠在一起了。
列表看起来能分页、能筛选，但底层仍是「内存里攒一大坨、周期性整库落盘」——和「直接往硬盘上的数据库文件里追加一条」不是一回事。功能继续加（参数转换、页面调试、协作同步）之后，这不是小优化能抹平的，而是存储方式选错了。
我们怎么改的：换成原生 SQLite，为「挂一整天」
我们一次性把抓包、协作等存储，从 sql.js 迁到原生 SQLite——就是操作系统里那种真正的本地数据库，DevPeek 通过原生模块直接读写磁盘上的文件。
动机很单纯：性能和内存。希望 DevPeek 可以连续跑一整天，内存也完全没压力。
改完以后，写入方式变了：
| 以前（sql.js） | 现在（原生 SQLite） | |
|---|---|---|
| 数据主要在哪 | 内存里越堆越大 | 在本地数据库文件里 |
| 怎么保存 | 隔一会儿整库拷贝写盘 | 来一条记一条，改哪里写哪里 |
| 挂一整天 | 内存容易往上走，偶尔卡 | 内存曲线平稳，列表跟手 |
改完以后，代理开着跑一天，列表照常翻、Mock 照点，不用为了「怕卡」而习惯性重启 DevPeek。
工程上，原生组件打包、发版会多费些事——我们愿意付这个成本，因为 DevPeek 的定位就是长时间陪联调，不能在存储层掉链子。
改完之后，你能感知到的变化
- 历史保留更多：单库可保留的抓包条数，从早期的约 1200 条提高到 5000 条（仍会自动删掉最旧的，避免无限膨胀）。
- 各功能各存各的：抓包、协作、调试 Network、重发历史分开存，互不相拖。
- 长时间联调更放心：这是这篇开发实录最想说的——我们踩过的坑是「挂久了内存和卡顿」；换存储之后，才敢说 DevPeek 适合在后台挂一整天。
若你以前某版 DevPeek 有过「越用越卡、只能重启」的体验，欢迎升级后试一下长会话；若仍有问题，到 GitHub Discussions 说说你的使用场景（大概挂多久、列表多少条），我们对照排查。
想了解抓包列表与历史记录怎么用，见 抓包与过滤。欢迎 下载 DevPeek 试用，联调时让代理多挂一会儿，看是否符合你的预期。