Nebula 1.2.0 把云存储支持从两家扩展到五家：新增七牛云 Kodo、AWS S3、Cloudflare R2，并继续支持阿里云 OSS、华为云 OBS。真正值得关注的不是“列表变长了”，而是新增三家都走 S3 兼容 API 和 AWS SigV4 签名，这意味着浏览、上传下载、分享、传输这些核心逻辑可以复用同一套路径。
同时，这个版本加入了应用内自动更新：启动时静默检查新版本，发现更新后可以一键下载、安装并重启。对桌面工具来说，这类能力会直接影响团队分发和用户升级成本。
五家云背后是一条统一协议路径
七牛云 Kodo、AWS S3、Cloudflare R2 的共同点，是都可以通过 S3 兼容 API 接入，并使用 AWS Signature Version 4 做请求签名。这样 Nebula 不需要为每一家云都维护一套完整的文件操作逻辑。
从工程角度看，这个选择很务实：
- 文件列表、对象上传、对象下载、删除、分享、传输任务可以抽象为对象存储操作。
- 不同云厂商的差异主要收敛到 endpoint、region、bucket、access key、secret key 等配置上。
- 新增云厂商时，优先验证 S3 兼容层，而不是重写一套业务流程。
这不代表所有 S3 兼容服务都完全一样。分页行为、权限模型、临时链接、地域命名、路径风格访问等细节仍可能不同。Nebula 1.2.0 的价值在于把主干操作统一了，但实际使用时仍要把每个云的边界条件测清楚。
SigV4 让“兼容”变得可验证
AWS SigV4 是 S3 生态里最常见的请求签名方式。客户端会把 HTTP 方法、路径、查询参数、请求头和 payload hash 组合成 canonical request，再用 secret key 派生签名密钥，最终生成 Authorization 头。
开发者不一定要手写 SigV4，但要理解它带来的约束：
- 系统时间偏差过大时，签名可能失败。
- endpoint、region、bucket 名称写错时，错误看起来可能像权限问题。
- 代理、网关或中间件如果改写了关键 header，也可能导致签名校验失败。
- R2、Kodo 这类 S3 兼容服务通常需要指定自家的 endpoint，而不是默认 AWS endpoint。
所以排查连接问题时，不要只盯着 access key。先确认 endpoint、region、bucket、时钟、权限策略，再看客户端日志。
可以这样实践：用 AWS CLI 预检 S3 兼容配置
在把配置填进 Nebula 之前，可以先用 AWS CLI 验证 S3 兼容访问是否通。下面命令适用于 S3 兼容服务的预检场景。运行前把占位值换成你的实际配置。
export AWS_ACCESS_KEY_ID="your-access-key"
export AWS_SECRET_ACCESS_KEY="your-secret-key"
export AWS_DEFAULT_REGION="auto"
# Cloudflare R2 示例：把 account id 和 bucket 换成自己的
aws s3api list-objects-v2 \
--endpoint-url "https://<account-id>.r2.cloudflarestorage.com" \
--bucket "your-bucket" \
--max-keys 5
如果是 AWS S3，可以去掉 --endpoint-url，并把 region 改成真实区域：
export AWS_ACCESS_KEY_ID="your-access-key"
export AWS_SECRET_ACCESS_KEY="your-secret-key"
export AWS_DEFAULT_REGION="ap-southeast-1"
aws s3api list-objects-v2 \
--bucket "your-bucket" \
--max-keys 5
如果是七牛云 Kodo 的 S3 兼容入口，可以这样改造。具体 endpoint 和 region 请以你控制台中的配置为准：
export AWS_ACCESS_KEY_ID="your-qiniu-access-key"
export AWS_SECRET_ACCESS_KEY="your-qiniu-secret-key"
export AWS_DEFAULT_REGION="your-region"
aws s3api put-object \
--endpoint-url "https://your-kodo-s3-endpoint" \
--bucket "your-bucket" \
--key "nebula-smoke-test.txt" \
--body ./nebula-smoke-test.txt
创建一个测试文件可以直接运行：
printf "hello from nebula smoke test\n" > nebula-smoke-test.txt
这类预检的好处是明确：如果 CLI 都无法列目录或上传对象，就先不要怀疑 Nebula 的 UI；问题大概率在凭证、endpoint、bucket 权限或网络链路上。
自动更新降低维护成本，也带来发布纪律要求
Nebula 1.2.0 新增应用内自动检测与一键升级：启动后静默检查，发现新版本时可以下载、安装并重启。对个人用户，这是少点手动下载；对团队内部推广，这是少一轮“你装的是哪个版本”的沟通。
但自动更新也要求发布流程更稳：
- 更新包需要可校验，避免下载损坏或被替换。
- 安装失败要能回退或至少保留旧版本可用。
- 企业网络里可能存在代理、证书拦截、下载域名白名单问题。
- 关键生产环境不要在重要传输任务进行中贸然重启升级。
换句话说，自动更新不是单纯的“更方便”，它把版本分发从用户手里拿回到应用内，发布质量和异常处理就更重要了。
接入建议：先验证主链路，再迁移日常任务
升级到 Nebula 1.2.0 后，可以按下面顺序落地：
- 先为每家云单独做最小权限的 access key，不要直接使用高权限主账号密钥。
- 用 AWS CLI 或同类工具验证 list、upload、download 三个基础动作。
- 再在 Nebula 中添加对应云存储连接，确认浏览、上传下载、分享、传输是否符合预期。
- 对大文件、批量目录、跨云传输做一次小规模压测。
- 打开自动更新前，确认团队网络允许下载更新包，并约定升级窗口。
Nebula 1.2.0 的方向很清楚：用 S3 兼容协议扩大云厂商覆盖，用应用内更新减少版本维护成本。真正落地时，重点不是把五家云都连上，而是把权限、endpoint、传输失败恢复和升级策略这些工程细节收紧。