因为这个项目优先追求的是稳定复用网页侧真实能力，不是做一个「看起来更轻」的抓包转发器。
直接封装网络包当然更省资源，但长期使用时通常有这些问题：
-
登录态不只是一个固定 Cookie
很多站点除了sessionKey，还依赖浏览器里的本地存储、页面初始化状态、动态 token 等运行时上下文。 -
前端协议不是静态不变的
有些请求字段是前端 JS 在运行时组装的，站点一改前端逻辑，纯抓包方案就容易失效。 -
更容易碰到风控
真实浏览器天然更接近站点预期的访问行为；纯脚本直连接口更容易因为指纹、请求时序、上下文缺失而被拦。 -
会话复用更自然
这个项目需要长期维持网页会话、支持断点续聊、支持账号切换后的调度。浏览器方案更容易和网页端保持一致。 -
调试成本更低
出问题时可以直接看真实页面、真实登录态、真实请求环境，而不是只盯着抓包日志猜协议哪里变了。
一句话说，这个项目是用更高的资源成本，换更强的稳定性、兼容性和可维护性。
当然，浏览器方案也有代价：更吃内存、冷启动更慢、调度逻辑更复杂。所以这不是最轻的方案，而是更适合「长期跑、尽量少因为站点变动而失效」的方案。