Cos.Client 初始化失败主因是密钥硬编码，须用cos.NewCredential从环境变量加载；region须与桶地域严格一致；超时需配http.Client和context；大文件用分片上传；GetObject须流式读Body；SignatureDoesNotMatch多因系统时间偏差超15分钟。
cos.Client 初始化失败：SecretId/SecretKey 不能硬编码
直接 panic 或报 CosError: invalid credentials，基本都是因为把密钥写死在代码里。SDK 不会自动读环境变量或配置文件，必须显式构造凭证对象。
- 用
cos.NewCredential创建凭证，SecretId和SecretKey必须从os.Getenv("TENCENTCLOUD_SECRET_ID")等安全来源加载 -
region必须和桶实际地域严格一致，比如桶在ap-guangzhou，就不能填ap-shanghai，否则返回 403 -
Endpoint可省略，SDK 会自动拼；但若用了 CDN 域名或内网接入点，必须传cos.WithBaseURL("https://my-bucket-1250000000.cos.ap-guangzhou.myqcloud.com")
上传卡住或 context deadline exceeded：超时没配对
调用 client.Object.Put 后长时间无响应，90% 是因为没设 HTTP 超时。SDK 默认用 http.DefaultClient，其 Transport 没配 Timeout，大文件或弱网下极易 hang 住。
- 初始化 client 时务必传自定义
http.Client：cos.WithHTTPClient(&http.Client{Timeout: 30 * time.Second}) - 上传操作本身也建议加 context 控制：
ctx, cancel := context.WithTimeout(context.Background(), 15*time.Second)，避免 goroutine 泄漏 - 单个文件 >100MB 别用
Put，改用MultipartUpload流程（InitiateMultipartUpload→ 多个UploadPart→CompleteMultipartUpload）
GetObject 返回空内容或 io.EOF：Body 没正确处理
调用 client.Object.Get 后读不到数据，不是 SDK bug，而是没按 HTTP 协议规范处理响应流。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
resp.Body是未读取的 stream，必须手动读完再close，不能一拿到就defer resp.Body.Close() - 检查状态码：
if resp.StatusCode != 200，COS 对不存在的 key 直接返回 404，SDK 不自动报错 - 大文件别用
io.ReadAll(resp.Body)，内存暴涨；应流式处理，例如io.Copy(dst, resp.Body)
PutObject 失败报 SignatureDoesNotMatch：本地时间偏移超限
错误信息含 RequestExpired 或签名不匹配，几乎全是系统时间不准导致。腾讯云要求客户端与服务端时间差 ≤15 分钟。
立即学习“go语言免费学习笔记（深入）”；
- 执行
ntpdate -u pool.ntp.org或启用systemd-timesyncd同步时间 - 容器环境尤其要注意：基础镜像可能没开 NTP，或挂载了 host 的 /etc/localtime 但没同步时钟
- CI/CD 流水线机器、离线开发机、老旧虚拟机是高发场景，上线前务必验证时间偏差
真正容易被忽略的是时间同步和 Body 生命周期——前者让请求在签名层就被拒，后者让连接复用异常、后续请求集体失败，且现象隐蔽，日志里只显示空响应或超时。
