王森的博客

看似非常复杂的大前端开发，最终无非就是在解决两个问题：解决不同层级下的通信问题同页面下的通信，例如 vue 的父子通信，或者 vuex不同页面下的通信，例如谷歌插件不同页面的 chrome.runtime.sendMessage不同进程下的通信，例如 electron 的 ipcRenderer.invoke不同服务下的通信，例如 electron 的 main.js 和本地 http.exe解决数据的存储问题同页面下的数据存储，例如 vuex 和 localStorage。

因为注入脚本是一整套塞进去的，字体，css，html 都应该打包在一个 js 里面，以 base64 方式注入，其中 dataUrlCondition 这个配置非常棒，只要将 maxSize 设置得足够大，就可以将字体文件也打包到 js 文件里面去，这样就特别方便 DOM 的注入和挂载。因为我们设定了 babel 的兼容 ES12，所以下面这些转化基本都用不到，因为 Chrome 能支持，所以也不需要这些插件，你可以直接用最新的语法，如?批量移除它们，proposal 这些都已经被作为正式版包使用了。

经过通信层面的优化后，我们不再走 Electron 提供的内置进程间通信 IPC，改为利用 Express 提供的 Http 本地服务来进行多处直达通信机制，同时利用本地 Sqlite 来保存大量数据，但 Express 提供的本地服务是支持并发请求的，而 Sqlite 是不支持行锁的机制，一旦有写入操作，Sqlite 都是直接锁库，除了采用单表单库减少锁库问题外，另外就是走队列的方式来逐个入库，避免写锁问题。

在产品迭代时，个人版产品已经将联系人和消息实时备份到本地，而消息的备份的目的仍然是为了快速查询对自己有用的上下文，并能快速定位到这些用户以及这些有用的信息。另外包括未来喂给 chatgpt-4o 的数据也是需要调用搜索获取的，也不是全量喂，以减少无用信息的资源浪费。

在网上看了很多帖子，也一直没有时间去看操作系统底层设计，之前一直想不通监听端口这个概念到底在程序层面怎么实现的，今天将我的猜想总结在这里，如有不对，欢迎拍砖，这里纯属记录下自己的整体构想。

之前写了一篇Electron通信的方式，讲述了一下三者之间的通信机制，比较恶心，后来发现有个@electron/remote，可以让渲染进程直接访问主进程，但遗憾的是，preload.js无法使用这个库，webview更是不可能直接触达主进程，总要通过preload.js绕一圈才能找到渲染进程。为此，我们需要一个新的方式，来解决所有通信链路的问题。

开发客户端时，为了应对不同客户的不同需求，大杂烩的客户端往往使得代码非常凌乱，补丁代码越堆越多，但是这并不能让产品的付费转化提高，每个用户都有自己的需求偏重，同时也更在意自己的需求的体验和稳定性，不断地增加更多功能，会使得系统过于庞大，同时还降低了系统的稳定，互相影响是难免的。但如果抽离不同功能形成新的版本，就会出现分裂，渐渐地就会出现底层数据结构的分裂，一旦分开就有走得快的，走得慢的，慢的和快的就会产生结构的不同，为了应对这种结构的自然变化，以及使用者的不可控（对方可能一直用着旧版本），这就造成了版本