遇到这种情况我太熟悉了，核心问题确实出在你使用的1.0.0版本GCP Libraries BOM上——这个版本是非常早期的GCP客户端库集合，当时还没有支持通过gcloud auth application-default login --impersonate-service-account这种本地模拟服务账号的凭据获取逻辑，所以你的Java代码在本地运行时，根本没加载到模拟账号的权限，才会报“匿名调用者无权限”的错误。而Cloud Run上正常，是因为GCP托管环境直接使用服务账号的默认凭据，不需要本地模拟的那套逻辑，旧版库能正常适配。

下面给你几个可行的解决思路：

1. 针对旧版库，手动实现模拟账号的凭据加载 #

既然无法直接升级框架依赖，你可以显式在代码中创建支持模拟的凭据，而不是依赖StorageOptions.getDefaultInstance()。具体步骤如下：

第一步：添加必要的依赖 #

在你的pom.xml中添加Google身份验证库的依赖（旧版库可能需要显式引入）：

<dependency>
    <groupId>com.google.auth</groupId>
    <artifactId>google-auth-library-oauth2-http</artifactId>
</dependency>

第二步：修改Storage实例的初始化代码 #

替换原来的getStorage()方法，手动构建带模拟账号的凭据：

private static Storage getStorage() throws IOException {
    // 获取本地默认凭据（来自gcloud auth application-default login）
    GoogleCredentials baseCredentials = GoogleCredentials.getApplicationDefault();
    
    // 创建模拟服务账号的凭据
    ImpersonatedCredentials impersonatedCredentials = ImpersonatedCredentials.newBuilder()
            .setSourceCredentials(baseCredentials)
            .setTargetPrincipal("<account-service-email@project.iam.gserviceaccount.com>")
            // 配置需要的权限范围，根据你的需求调整
            .setScopes(Arrays.asList(
                    "https://www.googleapis.com/auth/devstorage.read_write",
                    "https://www.googleapis.com/auth/logging.write"
            ))
            .setLifetime(3600) // 凭据有效期，单位秒
            .build();
    
    // 用模拟凭据初始化Storage
    return StorageOptions.newBuilder()
            .setCredentials(impersonatedCredentials)
            .build()
            .getService();
}

2. 临时替代方案：使用服务账号密钥文件 #

如果上面的代码调整太麻烦，可以临时用服务账号密钥文件来绕过模拟问题：

• 从GCP控制台下载目标模拟服务账号的JSON密钥文件
• 本地运行代码前，设置环境变量：

  export GOOGLE_APPLICATION_CREDENTIALS="/path/to/your/service-account-key.json"
  

• 这样你的代码就能直接加载该服务账号的凭据，本地运行时就能正常访问Storage和Logging了。不过这个方法不如模拟安全，建议只用于测试。

3. 长远解决方案：尽量升级依赖版本 #

如果你的框架允许，优先尝试升级libraries-bom的版本——你自己也提到新版（26.29.0）能正常工作，说明GCP后续版本已经修复了本地模拟服务账号的兼容性问题。可以逐步尝试升级到框架支持的较新版本，这样就能直接使用gcloud auth application-default login --impersonate-service-account的方式，不需要修改代码。

最后再确认下：你在Cloud Run上正常，是因为Cloud Run使用的是服务账号的工作负载身份凭据，和本地模拟的凭据获取逻辑完全不同，旧版库能适配这种环境，但本地的模拟逻辑是后来才加入客户端库的，所以早期版本不支持。

备注：内容来源于stack exchange，提问作者Luan C Martins