这个问题可能在我从 Office 2019 切换到 365 时开始出现，但是我最近做了很多升级（Windows 11、Server 2022 等），以至于我的记忆很模糊。
在过去的 6 年里，我开发了大量启用宏的 Excel 表，其中大多数都是为各种项目复制的模板。所有这些文件的代码都受密码保护（工具 > VBAProject 属性 > 保护 > 锁定项目以供查看）它们都位于中央文件共享中（我们将其称为“\FileShare”）。多年来，此位置已添加到受信任位置（“允许我网络上的受信任位置”= true，“此位置的子文件夹也受信任”= true）。
一开始我遇到了一些问题，看似随机的文件开始“损坏”，或者在尝试运行宏或保存文件时弹出“灾难性错误”窗口。我找到了解决这些问题的最佳方法：
- 将“AccessibilityCplAdmin 1.0 类型库”添加到引用
- 文件 > 选项 > 信任中心 > 信任中心设置 > 宏设置 > 信任对 VBA 项目对象模型的访问 = True
- 在某些情况下，导出代码模块并从头开始创建模板。
但是，我每晚都会通过任务管理器自动更新（运行宏）一些“概览”电子表格。这是通过一些通过 cscript 调用的简单 VB 脚本文件完成的。大约每周 1-2 次，这些文件中的一个或多个在夜间无法运行。然后我打开文件，发现所有模块都还在那里，但单击它们却看不到代码。我还发现尝试运行宏会冻结文件。此外，尝试添加模块也会冻结文件。
我发现的唯一解决方法是将文件移动到不受信任的位置（桌面），打开文件，打开 VBA 窗口，解锁宏，调试>编译代码，保存文件，然后移回 \FileShare。我甚至注意到，在执行此操作时，将文件移回时，文件大小总是会增加（就像它突然“添加回”了 VBA 代码一样）。但是，这不是永久性的修复，我发现问题不断重复出现。令人沮丧的是，多年来一直运行良好的东西突然开始出现问题。
我尝试重新安装 Office。我甚至拿了一台备用台式机并将所有内容迁移到上面，只是为了确保这不是特定于机器的问题。问题仍然存在。
如果这对我来说是“新常态”，那就这样吧。但我至少想弄清楚为什么。
编辑（03/13/24）
我现在记得，这个问题是在我从使用 x32 Excel 切换到 x64 Excel 时开始的。接受的答案恰好解决了这个问题。
答案1
升级到 Excel 365 后工作簿中的 VBA 停止工作 - VBA 编译问题
在我和我的客户不断努力解决极其烦人的 Excel VBA 文件损坏问题（工作簿中的 VBA 代码在升级到 Excel 365 后停止工作）的过程中，我想我可能找到了一些值得尝试的新方法。请参阅下面的 Stackoverflow 链接，其中打印了相关的建议解决方案。我刚刚将此更改应用于我的 PC 注册表，但我犹豫是否建议其他人这样做，因为我显然不是进行此类 PC 系统更改的专家。https://stackoverflow.com/questions/69018012/vba-workbooks-stop-working-with-upgrade-to-excel-365-vba-compiling-issue
我想我也许在这个帖子中找到了答案：https://lnkd.in/gU3E2bfG
根据该线程：“原因是 Excel 无法正确保存 VBA 代码的编译状态，并且 64 位 Excel 在打开受影响的 Excel 文件时无法从该问题中恢复（32 位通常可以）。仅针对 Excel 2016 发布了修复程序，而未针对其他版本发布”。这确实可以证实这是 Excel 中的一个错误，并解释了为什么我们只在 365 64 位 Excel 中看到此问题。
这也解释了为什么我的手动编译修复有效。根据我找到的文章，有一个更可持续的修复方法。您可以更改 Excel 的注册表并强制 VBA 准确编译。
要实施永久修复：
- 打开开始菜单，输入“reg”，然后选择“注册表编辑器”。
- 导航到：Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Excel\options。
- 在编辑菜单上，指向新建，然后单击 DWORD 值。
- 键入 ForceVBALoadFromSource，然后按 Enter。
- 在“详细信息”或“名称”窗格中，右键单击“ForceVBALoadFromSource”（刚刚添加的），然后单击“修改”。
- 在数值数据框中，键入 1，然后单击确定。