本地Docker部署Word JS加载项侧加载失败，求崩溃排查信息获取方法

我之前也碰到过类似的本地Office加载项崩溃问题，给你几个能深挖错误信息的方向，应该能帮你定位到根因：

• 启用Office加载项的详细日志记录
  Office本身提供了加载项的调试日志功能，你可以通过修改注册表开启：

  1. 打开注册表编辑器（regedit.exe）
  2. 导航到HKCU\Software\Microsoft\Office\16.0\Wef\Developer（如果路径不存在就手动创建）
  3. 添加两个DWORD值：
     • EnableLogging 设为 1
     • LogLevel 设为 3（最高日志级别）
  4. 可以额外添加字符串值LogPath指定日志保存路径（比如C:\OfficeAddinLogs）
     重启Word后尝试加载加载项，日志里会包含加载过程中的网络请求、权限检查、错误栈等细节。

• 捕获WebView2的调试日志
  你的Word版本（2002 build 12527）大概率使用WebView2控件渲染加载项，你可以通过设置环境变量开启WebView2的详细日志：

  1. 打开命令提示符，执行：

     setx WEBVIEW2_DEBUG_LOG_FILE "C:\WebView2Logs\wv2.log"
     setx WEBVIEW2_DEBUG_LOG_LEVEL 0
     

  2. 从这个命令提示符窗口启动Word（确保环境变量生效）
     尝试加载加载项后，查看生成的日志文件，里面会包含WebView加载页面时的所有错误，包括证书验证、JavaScript异常、资源加载失败等。

• 检查Docker容器的访问日志
  既然加载项托管在本地Docker里，先确认容器本身有没有收到Word的请求，以及请求的响应状态：

  1. 找到加载项容器的ID：docker ps
  2. 查看容器的访问日志：docker logs <container-id>
     如果看到Word的请求返回了4xx/5xx状态码，那问题出在容器端的服务，比如路由错误、服务崩溃等。

• 验证HTTPS证书的兼容性
  虽然IE和Edge访问没报错，但Office的WebView控件对证书的校验可能更严格：

  • 检查证书的Subject Alternative Name (SAN) 字段是否同时包含dev.local和你的本地IP地址
  • 确认证书已经导入到本地计算机的受信任根证书颁发机构（而不是仅用户存储），因为Office进程可能以系统权限运行
    可以用命令certutil -verify <你的证书文件路径>检查证书链的完整性。

• 使用Office加载项调试工具
  微软官方的Office Add-in Debugger Tool可以直接附加到Word进程，捕获加载项的控制台输出、网络请求和JavaScript错误，比Edge开发者工具更稳定（不会轻易崩溃）。你可以通过Office Developer Center获取这个工具，附加后再触发加载项崩溃，就能看到实时的错误信息。

内容的提问来源于stack exchange，提问作者T. Altena