Java中基于SAS Token访问Azure WASB容器失败排查求助

从你的测试代码和描述来看，核心问题大概率出在SAS令牌的生成与凭证传递方式上，另外也可以从几个方向进一步排查：

1. SAS令牌传递错误（最可能的原因） #

你当前的代码把容器URI和SAS令牌拼接在一起，作为StorageCredentialsSharedAccessSignature的参数，但这个类只需要纯SAS令牌部分（即?后面的字符串，甚至不需要?），不需要包含前面的容器URL。

错误的写法：

// 错误：sas变量包含了容器URI + ? + SAS令牌
String sas = blobContainer.getUri().toString() + "?" + blobContainer.generateSharedAccessSignature(policy, null, null, SharedAccessProtocols.HTTPS_ONLY);
StorageCredentials credentials = new StorageCredentialsSharedAccessSignature(sas);

修正后的写法：

// 只获取纯SAS令牌（generateSharedAccessSignature返回的就是不带?的令牌）
String sasToken = blobContainer.generateSharedAccessSignature(policy, null, null, SharedAccessProtocols.HTTPS_ONLY);
// 凭证只传入SAS令牌
StorageCredentials credentials = new StorageCredentialsSharedAccessSignature(sasToken);
// 容器URI保持不变
URI blobUri = new URI(blobContainer.getUri().toString());
CloudBlobContainer sasContainer = new CloudBlobContainer(blobUri, credentials);
sasContainer.downloadAttributes(); // 尝试执行此操作

2. 时间范围与时区问题 #

你用LocalDate转换为Date来设置SAS的起止时间，LocalDate.now()会使用本地时区，但Azure存储服务使用UTC时间。虽然你设置了前后两年的范围，理论上不会出现时间过期问题，但如果你的本地时区和UTC差异较大，可能导致实际生效时间不符合预期。可以改成UTC时间来规避：

// 使用UTC时间设置起止时间
Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("UTC"));
cal.add(Calendar.YEAR, -2);
policy.setSharedAccessStartTime(cal.getTime());
cal.add(Calendar.YEAR, 4); // 因为刚才减了2，现在加4等于加2年
policy.setSharedAccessExpiryTime(cal.getTime());

3. 存储账户权限与网络配置 #

• 检查存储账户的防火墙和虚拟网络设置：如果你的测试环境IP不在允许列表中，即使SAS正确，也会被拒绝访问。测试阶段可以临时设置为“允许从所有网络访问”。
• 确认存储账户的Blob服务权限：确保账户本身有Blob容器的读写权限（不过你用账户密钥能成功下载属性，这部分应该没问题，但可以再确认）。

4. SDK版本兼容性 #

如果你使用的是较旧版本的Azure Storage SDK，可能存在API行为差异。建议确认使用的是最新稳定版的azure-storage-blob依赖（比如通过Maven/Gradle管理），避免旧版本的bug。

内容的提问来源于stack exchange，提问作者Dave McGinnis