1、立项背景与产品问题
大量企业的报表、台账、审批流至今跑在 Excel / Word / PowerPoint 的 VBA 里。这些工程的源码不是一个可以直接 diff 的文件夹，而是嵌在 Office 二进制文件里的一个「工程包」：改一行代码要先打开 Office、进 VBE、找到模块、改完再编译、再关掉。一个稍有规模的项目往往附几十个 xls，人工逐个编译一遍要几个小时，而且极易漏改、改错后无法回滚。
2、行业场景与业务背景
财务、制造、政务等行业的存量 Office 自动化资产规模巨大，维护方常是企业内部的 IT 支持组，人员流动后代码几乎无人敢动。项目目标是把这个过程做成一条命令：在 VS Code 里批量提取、编辑、编译、回写，让 VBA 维护第一次拥有现代编辑器该有的体验。
（1）工程解析：用 olevba 打开 Office 文件，把 VBA 工程结构（模块、类模块、窗体、引用）还原成文件树；
（2）侧边栏与项目树：在 VS Code 侧边栏展示工程结构与环境状态，支持直接打开编辑；
（3）编译编排：把编辑后的源码回写进工程，调用 Office 的 VBA 编译器完成编译，再把 bin 回写原文件；
（4）批量与并发：一次导入整个目录，按文件并行编译，带失败重试与结果汇总；
（5）环境检测：识别本机 Office 位数、版本、信任中心设置，编译前给出可操作的提示。
业务流程：右键文件夹或文件 → 选择导入 VBA 工程 → 侧边栏出现工程树 → 在编辑器里改代码 → 右键目标节点选择编译（或对整批选择批量编译）→ 扩展回写源码、驱动 Office 编译、收集编译错误 → 输出面板汇总每个文件的成功/失败与错误行 → 需要时一键重编失败项。
1、整体架构与技术栈
标准的 VS Code 扩展架构：TypeScript 写扩展本体，分四层——解析层（olevba 解析 Office 复合文档，抽工程流与压缩源码）、命令层（注册右键菜单与命令面板入口）、编排层（批量扫描 + 并发调度 + 重试）、UI 层（侧边栏视图、项目树、环境状态面板）。编译本身不自己实现，而是桥接本机 Office 的 VBA 编译器，扩展只负责「把源码放进去、把编译触发起来、把结果读回来」这三件事。并发用可控的 Promise 池，避免一次性拉起几十个 Office 进程把机器拖死。
2、负责范围与量化结果
独立开发。规模：src 下 14 个 TypeScript 文件约 4100 行。已完成能力：olevba 集成解析、Excel / Word / PowerPoint 三宿主兼容、智能编译器推荐、单文件编译、批量编译、并发编译、专用侧边栏与项目树、右键菜单集成、编译结果汇总，首个完整版即覆盖上述全部功能。
3、难点与解决方案
难点一：VBA 工程不是纯文本。它是 Office 复合文档里的一个压缩流，直接当文本读写会破坏结构。解决办法是严格走 olevba 的读写接口，只操作源码模块层，其他流保持原样。
难点二：并发编译互相踩文件。多个 Office 进程同时操作同一个临时目录或同一个 Office 实例时会随机失败。解决办法是给每个任务分配独立的临时工作目录，并用文件锁保证同一个源文件不会被两个任务同时处理。
难点三：COM 资源不释放。驱动 Office 编译会创建 COM 对象，异常路径下不释放就会在后台残留一堆 Excel 进程。解决办法是统一用 try/finally 包裹，所有对象在 finally 里显式释放，并在扩展停用时做一次兜底清理。
评论