[{"data":1,"prerenderedAt":57},["ShallowReactive",2],{"case-dev-build-log-sqljs-to-better-sqlite3-zh":3,"blog-list-zh":13},{"slug":4,"title":5,"summary":6,"date":7,"featured":8,"seoDescription":9,"series":10,"seriesOrder":11,"html":12},"dev-build-log-sqljs-to-better-sqlite3","抓包历史为什么从 sql.js 迁到原生 SQLite","早期 DevPeek 用纯 JavaScript 版 SQLite 存抓包记录，联调一忙就占内存、列表发紧。我们换成系统级原生 SQLite 后，代理可以连续挂一整天，内存也稳。","2026-08-05",false,"DevPeek 开发实录：抓包历史存储从 sql.js 换成原生 SQLite，解决长时间联调内存上涨、列表卡顿，让代理可以挂一整天。","dev-build-log",1,"\u003Ch2>我们遇到的坑：代理挂久了，人比电脑先扛不住\u003C\u002Fh2>\n\u003Cp>DevPeek 是联调工具，不是「抓几个包就关」。很多人会让代理开着，手机或 WebView 一直走流量，列表里堆几千条请求，调试页还要翻上午抓过的包。\u003C\u002Fp>\n\u003Cp>从 v1.1.4 起，抓包记录会\u003Cstrong>写到本地\u003C\u002Fstrong>，重启应用也能看近期历史；脚本改过的请求头、响应体也会一并保存。后来协作消息、调试页里的 Network 记录、重发历史，也都需要长期留着。\u003C\u002Fp>\n\u003Cp>一开始，我们选了一种\u003Cstrong>跑在 JavaScript 里的 SQLite\u003C\u002Fstrong>（叫 sql.js，常见于网页里做本地存储）。接入快、不依赖系统原生组件，早期功能少的时候够用。\u003C\u002Fp>\n\u003Cp>联调场景一忙起来，坑就暴露了。\u003C\u002Fp>\n\u003Ch2>现象：越抓越沉，像「该重启了」\u003C\u002Fh2>\n\u003Cp>你自己用 DevPeek 时，如果遇到过下面几种情况，很可能就是同一类问题：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>代理从上午开到傍晚，\u003Cstrong>电脑越来越卡\u003C\u002Fstrong>，任务管理器里 DevPeek 占的内存慢慢往上走。\u003C\u002Fli>\n\u003Cli>列表里请求一多，\u003Cstrong>翻页、搜索、点详情\u003C\u002Fstrong>偶尔顿一下；Mock、断点还在跑，整机像被拖住。\u003C\u002Fli>\n\u003Cli>心里默认「联调结束关一下就好」——工具本该在后台默默干活，却像\u003Cstrong>挂久了就得重启\u003C\u002Fstrong>。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>根因在我们这边：\u003Cstrong>sql.js 把整库放在内存里\u003C\u002Fstrong>。每来一条抓包、每改一次请求详情，我们都要把\u003Cstrong>越堆越大的整份数据库\u003C\u002Fstrong>拷贝一遍再写回磁盘——相当于每隔一小段时间，把越堆越厚的笔记本从头到尾复印一次。\u003C\u002Fp>\n\u003Cp>抓包越多、每条请求的 Header\u002FBody 越大，复印就越慢、内存峰值越高。代理同时还要解密 HTTPS、跑 Mock、拦断点，卡顿就叠在一起了。\u003C\u002Fp>\n\u003Cp>列表看起来能分页、能筛选，但底层仍是「内存里攒一大坨、周期性整库落盘」——和「直接往硬盘上的数据库文件里追加一条」不是一回事。功能继续加（参数转换、页面调试、协作同步）之后，\u003Cstrong>这不是小优化能抹平的\u003C\u002Fstrong>，而是存储方式选错了。\u003C\u002Fp>\n\u003Ch2>我们怎么改的：换成原生 SQLite，为「挂一整天」\u003C\u002Fh2>\n\u003Cp>我们\u003Cstrong>一次性\u003C\u002Fstrong>把抓包、协作等存储，从 sql.js \u003Cstrong>迁到原生 SQLite\u003C\u002Fstrong>——就是操作系统里那种真正的本地数据库，DevPeek 通过原生模块直接读写磁盘上的文件。\u003C\u002Fp>\n\u003Cp>动机很单纯：\u003Cstrong>性能和内存\u003C\u002Fstrong>。希望 DevPeek 可以\u003Cstrong>连续跑一整天，内存也完全没压力\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Cp>改完以后，写入方式变了：\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>\u003C\u002Fth>\n\u003Cth>以前（sql.js）\u003C\u002Fth>\n\u003Cth>现在（原生 SQLite）\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>数据主要在哪\u003C\u002Ftd>\n\u003Ctd>内存里越堆越大\u003C\u002Ftd>\n\u003Ctd>在本地数据库文件里\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>怎么保存\u003C\u002Ftd>\n\u003Ctd>隔一会儿整库拷贝写盘\u003C\u002Ftd>\n\u003Ctd>来一条记一条，改哪里写哪里\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>挂一整天\u003C\u002Ftd>\n\u003Ctd>内存容易往上走，偶尔卡\u003C\u002Ftd>\n\u003Ctd>内存曲线平稳，列表跟手\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>改完以后，\u003Cstrong>代理开着跑一天，列表照常翻、Mock 照点，不用为了「怕卡」而习惯性重启 DevPeek\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Cp>工程上，原生组件打包、发版会多费些事——我们愿意付这个成本，因为 DevPeek 的定位就是\u003Cstrong>长时间陪联调\u003C\u002Fstrong>，不能在存储层掉链子。\u003C\u002Fp>\n\u003Ch2>改完之后，你能感知到的变化\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>历史保留更多\u003C\u002Fstrong>：单库可保留的抓包条数，从早期的约 1200 条提高到 \u003Cstrong>5000 条\u003C\u002Fstrong>（仍会自动删掉最旧的，避免无限膨胀）。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>各功能各存各的\u003C\u002Fstrong>：抓包、协作、调试 Network、重发历史分开存，互不相拖。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>长时间联调更放心\u003C\u002Fstrong>：这是这篇开发实录最想说的——我们踩过的坑是「挂久了内存和卡顿」；换存储之后，才敢说 DevPeek 适合\u003Cstrong>在后台挂一整天\u003C\u002Fstrong>。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>若你以前某版 DevPeek 有过「越用越卡、只能重启」的体验，欢迎升级后试一下长会话；若仍有问题，到 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FGYPengDev\u002Fdevpeek\u002Fdiscussions\">GitHub Discussions\u003C\u002Fa> 说说你的使用场景（大概挂多久、列表多少条），我们对照排查。\u003C\u002Fp>\n\u003Chr>\n\u003Cp>想了解抓包列表与历史记录怎么用，见 \u003Ca href=\"\u002Fdocs\u002Fcapture\u002F\">抓包与过滤\u003C\u002Fa>。欢迎 \u003Ca href=\"\u002F\">下载 DevPeek 试用\u003C\u002Fa>，联调时让代理多挂一会儿，看是否符合你的预期。\u003C\u002Fp>\n",{"items":14},[15,16,24,30,38,44,51],{"slug":4,"title":5,"summary":6,"date":7,"featured":8,"seoDescription":9,"series":10,"seriesOrder":11},{"slug":17,"title":18,"summary":19,"date":20,"featured":8,"seoDescription":21,"series":22,"seriesOrder":23},"mock-map-route-split-api","API 已迁新服务，前端还没发版？用「转发规则」联调","服务拆分后，前端仍请求旧 API，订单接口却已经迁到新服务。使用 DevPeek「转发规则」无需修改前端代码，即可把指定接口转发到新域名；若新服务未完成，还可以用 Mock 先跑通页面。","2026-07-26","微服务联调与 API 域名迁移：用 DevPeek「转发规则」做 API 转发，不改前端即可把旧域名请求指到新服务；服务迁移未完成时可用 Mock 先验页面。附接口联调 Demo。","api-debug-new-tricks",2,{"slug":25,"title":26,"summary":27,"date":28,"featured":8,"seoDescription":29,"series":22,"seriesOrder":11},"api-param-encryption-debug","H5 接口参数加密？DevPeek 一键解密调试","联调时接口参数 AES 加密看不到明文？用 DevPeek 参数转换功能，填好密钥和 IV 就能自动解密，还能改参重放。","2026-07-18","用 DevPeek 参数转换功能解密 AES-GCM 加密的 H5 API 请求，支持双向转换、明文编辑、调试重放。",{"slug":31,"title":32,"summary":33,"date":34,"featured":35,"seoDescription":36,"series":37,"seriesOrder":23},"h5-debug-console-mock","H5 调试实战（二）：Android WebView 白屏排查，从 Console 远程定位到 Mock 验证","活动 H5 在部分 Android 设备中点击按钮后白屏，请求全部 200 却没有页面反馈。通过 DevPeek Console 获取线上 WebView 运行日志，远程 eval 确认 polyfill 覆盖问题，再使用 Mock 验证异常状态下的降级页面。","2026-07-13",true,"H5 调试实战第二篇：排查 Android WebView 白屏问题。通过 Console 远程调试定位 JavaScript polyfill 兼容问题，并结合 Mock 验证接口异常场景下的页面降级逻辑。","h5-debug",{"slug":39,"title":40,"summary":41,"date":42,"featured":35,"seoDescription":43,"series":37,"seriesOrder":11},"wechat-h5-storage-debug","H5 调试实战（一）：微信 H5 localStorage 调试，在电脑上修改真机缓存","微信 H5 换测试号后头像仍显示旧用户，抓包确认接口正常，却定位到 localStorage 遗留旧数据。本文记录一次真实联调过程，以及如何在电脑上查看、修改微信 WebView 的 localStorage、sessionStorage 和 IndexedDB。","2026-07-11","微信 H5 调试实战：通过真实案例定位 localStorage、sessionStorage、IndexedDB 导致的数据缓存问题，对比 vConsole、Remote Debug 等方案，介绍真机 WebView 调试思路。",{"slug":45,"title":46,"summary":47,"date":48,"featured":35,"seoDescription":49,"series":50,"seriesOrder":23},"why-we-built-devpeek-h5-debug","我们为什么做 DevPeek（二）：App 里那页 H5，在电脑上也能对着查","登录接口用参数转换啃下来了，活动页 H5 却在 App WebView 里才崩。真机 remote debug 折腾一圈，DOM 和抓包还是两拨窗口——于是把镜像和自研调试面板收进 DevPeek。","2026-07-10","DevPeek 起源系列第二篇：App 内嵌 H5 只在真机出问题、remote debug 与抓包割裂的联调痛点，以及调试 Tab 如何把页面镜像到电脑并用自研面板查 DOM、Console 与 Network。","origin",{"slug":52,"title":53,"summary":54,"date":55,"featured":35,"seoDescription":56,"series":50,"seriesOrder":11},"why-we-built-devpeek","我们为什么做 DevPeek（一）：HTTPS 解密了，Body 还是天书","版本日前那晚，TLS 早就解开了，改请求里一个字段却还要翻脚本加解密。于是萌生做一个把业务加解密收进代理的工具——DevPeek 从这儿开始。","2026-07-09","DevPeek 起源系列第一篇：联调时请求体加解密的手工折腾，以及为什么先做一款把业务加解密收进代理的工具。",1785900957101]