如何查看Excel 2016 VBA中已编译子程序的大小？

好问题！当碰到VBA的Procedure too large错误时，确实需要关注编译后的过程大小——可惜VBA并没有内置功能直接让你查看单个子程序的编译后字节数，但有几个间接方法能帮你评估重构效果，或者验证拆分后的代码是否符合64K的限制：

• 对比VBA项目二进制文件的整体大小
  把你的.xlsm文件后缀改成.zip，解压后找到xl/vbaProject.bin文件，这个文件包含了所有编译后的VBA代码。虽然没法精准定位单个子程序的大小，但你可以在重构前后对比这个文件的体积变化，间接判断拆分代码的效果。需要注意的是，这个文件还包含模块的元数据、表单绑定代码等其他内容，所以只能作为整体趋势的参考。

• 逐步拆分+编译验证
  既然你已经在重构，每次把大子程序拆分成几个小模块后，直接尝试编译验证：按Ctrl+G打开立即窗口，输入ThisWorkbook.VBProject.VBComponents("你的模块名称").Compile并回车。如果不再弹出Procedure too large错误，说明拆分后的每个子程序都在64K的限制内。这种方法虽然给不出具体数值，但能直接确认重构是否解决了核心问题，你也可以通过拆分的粒度大致推断原程序的大小范围。

• 借助第三方反编译工具
  有一些第三方VBA反编译工具可以加载vbaProject.bin文件，反编译后能查看每个过程的编译代码长度。不过这类工具主要用于逆向工程场景，使用时要注意版权和文件安全，同时需要验证其对Excel 2016 VBA项目的兼容性。

另外你提到的点非常准确：编译后的代码大小和代码行数、纯文本代码的大小都不是一一对应的——注释、空白行不会被编译，而不同语句的编译字节数差异很大（比如复杂表达式、函数调用都会显著影响体积）。比尔·盖茨那句“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”用来形容这类老旧代码的问题简直太贴切了，拆分子程序不仅能解决编译大小的瓶颈，更是提升代码可读性、可维护性的关键第一步。

内容的提问来源于stack exchange，提问作者a.t.