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

原文出处本文首发于 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 的定位就是长时间陪联调不能在存储层掉链子。改完之后你能感知到的变化历史保留更多单库可保留的抓包条数从早期的约 1200 条提高到5000 条仍会自动删掉最旧的避免无限膨胀。各功能各存各的抓包、协作、调试 Network、重发历史分开存互不相拖。长时间联调更放心这是这篇开发实录最想说的——我们踩过的坑是「挂久了内存和卡顿」换存储之后才敢说 DevPeek 适合在后台挂一整天。若你以前某版 DevPeek 有过「越用越卡、只能重启」的体验欢迎升级后试一下长会话若仍有问题到 GitHub Discussions 说说你的使用场景大概挂多久、列表多少条我们对照排查https://github.com/GYPengDev/devpeek/discussions相关链接DevPeek 官网与下载https://devpeek.ypgao.com/抓包与过滤文档https://devpeek.ypgao.com/docs/capture/本文原文https://devpeek.ypgao.com/blog/dev-build-log-sqljs-to-better-sqlite3/