```go
import (
"github.com/Azure/azure-sdk-for-go/sdk/azidentity"
"github.com/Azure/azure-sdk-for-go/sdk/storage/azblob"
)
cred, err := azidentity.NewDefaultAzureCredential(nil)
if err != nil { /* handle */ }
client, err := azblob.NewClient("https://YOUR-ACCOUNT.blob.core.windows.net", cred, nil)
if err != nil { /* handle */ }
_, err = client.UploadFile(ctx, "[container]", "[blob-name]", file, nil)
```
Go-specific traps:
- **Module split.** azblob lives in `sdk/storage/azblob`, identity in `sdk/azidentity`. Version-skew between the two modules breaks auth in confusing ways; pin both and upgrade together.
- **No from_connection_string in newer versions.** If you are porting Python/Node code that used a connection string, the Go path is `NewClientWithSharedKeyCredential` or SAS. Prefer identity.
- **Upload APIs.** `UploadFile` (io.File), `UploadStream` (io.Reader), `UploadBuffer` ([]byte). Large uploads default to block blobs with sensible chunking; you rarely need to tune it.
- **Context everywhere.** Every call takes a context. Timeouts on the context are the right way to bound a hung upload; the SDK does not add one for you.
- **Data roles, again.** Storage Blob Data Contributor at the storage account scope. The language changes; the RBAC requirement does not.
Verify with `client.NewContainerClient("[container]").NewBlobClient(...)` then a download round-trip comparing bytes.