我遇到了随机宏损坏，导致我无法打开工作簿。
我必须禁用所有宏而不发出通知，然后打开工作簿并重新编译宏，保存关闭。然后启用宏并打开工作簿，然后工作簿就可以正常打开。刷新宏几乎就像有助于重新打开工作簿一样。我检查了我的部分模块，其中一些超过了 64kb 的大小。我读过一些关于导致损坏的模块大小限制的文章。
有人验证过这是否也适用于 Excel 365 或任何导致宏损坏的原因吗？
答案1
64KB 的限制不是导出文件的大小，而是编译模块的最大大小。
如果你的模块少于10K行，则可以编译。
一个繁重但可能仍然健康的模块最多有 1K 行 - 当导出到文本文件时似乎在 40KB 左右徘徊；64KB 对我来说并不完全不雅，尽管它是代码量肯定超过 1K 行，因此可能需要进行一些调整。
如果你的模块名为 egModule8或Utilities，请验证如何有凝聚力它们的成员是 - 它们都与相同的功能相关吗？还是感觉像是随机函数被扔在那里？
查找重复的代码，重构它。提取方法，参数化它们，观察模块消失，同时保留其所有功能。
VBA 代码的内部存储机制 20 年来都没有改变过 - 我看不出它最近有什么改变的理由，尤其是因为 VBA 现在基本已经冻结，而存储机制中的任何变化都会破坏各地的数百万个东西。
但是，O365 中最近发生了一些变化，这并非不可能（您是否正在使用权威资讯构建？），并且出现问题并且您的工作簿以某种方式损坏了....但如果您的模块略高于 64KB文本源代码，它不太可能相关：编译后的代码会比这小得多......假设项目编译。
答案2
每程序. 引自程序太大
编译后，过程的代码不能超过 64K。此错误的原因和解决方案如下：
- 此过程的代码在编译时超过 64K。将此过程以及任何其他大型过程拆分为两个或多个较小的过程。
我在 Access 2013 中使用一个 811KB 的 VBA 文件。它包含许多小程序，但从未引起任何问题。
因此，回答 OP 的问题：如果你的项目中有一个巨大的子程序，请将其拆分。否则，你报告的模块大小就没什么可担心的了。