一个 18,525 行文件的拆分之道

这个插件目前是一个包。它的宿主半面与浏览器半面、语义引擎与白板、团队层与日历，全部住在同一个 package.json 之下。改前端要连带上 12.5 GB 的 Python 侧，装记忆检索就得连白板看板一起装。

拆分是用户提出的诉求。本文回答三个问题：能不能拆、该按什么维度拆、真正的障碍在哪。

一　先看结构

两个文件占去整个目录超过一半的代码量。这个比例本身就是拆分难度的指标。

二　六十八个叶子

这是一个星形拓扑：中心是编排层，外围是叶子。已有若干成组的叶子模块共用同一批依赖，天然构成子包候选：

三　拦路的那一个类

把叶子搬走之后，剩下的还是那座山。

MemoryEngine 一个类横跨一万余行。它的 261 个方法按语义分域之后，分布是这样的：写盘 17、runtime 13、白板 8、注入 7、配置 6、反思 5、检索 4、日历 3、技能 2、诊断 1——未归类 195 个。

最后一行的数字才是重点。近四分之三的方法无法归入任何功能域——它们共享状态、互相调用、边界模糊。按域拆分意味着要给这 261 个方法划出一条清晰的缝，而这条缝目前不存在。

因此可行性判断是：可拆，但这一刀不能先切这里。

四　对照组

「能不能拆」这个问题不必推演，有现成的答案。同一生态里有一个 22 子包的工程在生产运行。

宿主的多包组合机制、独立显示与独立开关，在对照组上都已得到验证。本仓可以直接套用，不需要新的运行时能力。

五　最大的陷阱

拆分过程中最需要警惕的不是打包机制，而是一处语义细节：patch 文件的 insert 是「插入一行」，不是「替换」。

同一个包被安装两次，会得到两个 id 相同的行，从而触发插件重复注册。搬迁时必须保证旧行被移除，且这一对动作要配断言守住。

六　三阶段

按风险递增排序，路径是这样：

第一阶段，拆「宿主半面 / 浏览器半面」。零语义风险，收益最大：前端改版不再带上 Python 侧，首次安装更快。

第二阶段，把叶子模块整组包化。低风险，且前述六个候选子包都有明确的叶子证据。

第三阶段，动 MemoryEngine。高风险，须单独立项，且前置条件是完成解耦。

关于收益需要一句澄清：拆分是结构治理，不是减重。总代码量不会因此减少——它换来的是可单独开关、可单独发版、故障隔离，以及首次安装不必再拖着一个整体。