背景
我的博客使用 GitHub Pages 托管静态站点，但图片处理一直是个问题。最初，我将图片直接存放在项目仓库中，随之而来的是两个问题：
- 仓库臃肿: 图片作为二进制文件存放进仓库，会导致仓库体积膨胀
- 引用困难: 需要手动推送，然后复制提供的URL，步骤繁琐
我了解到，图床是这类问题一个很好的解决方案
1. 对象存储与存储桶
我使用阿里云的 OSS 用于图片的存储。查阅相关教程，我了解到：
OSS 像一个全球化的、自动化的智能仓储网络。它采用“扁平”结构，为存入的每个文件（对象）提供一个唯一的URL地址，可通过此地址随时访问
“桶 (Bucket)”是这个仓储网络里租用的一个专属仓库，有几个关键属性：
- Bucket 名称:
helpfulcraft-blog(唯一) - 地域:
华北2（北京） - 读写权限: 关键的配置
- 阻止公共访问: 关闭，否则图床无法公开访问
- 读写权限:
公共读。任何人都可以查看图片
2. 访问控制 (RAM)
在我准备为图床工具配置访问密钥时，阿里云提示：“不建议使用云账号 AccessKey … 具有账号的完全权限 …”，并建议使用 RAM 用户 AccessKey
深入了解后，我理解了其中的差异：
- 云账号 AccessKey (主密钥): 账户的“万能钥匙”，拥有所有资源的完全控制权。将其泄露给第三方应用，风险极高
- RAM 用户 AccessKey (子密钥): 为一个“子账户”生成的专用钥匙。可以精确地授权这把钥匙只能执行特定操作（例如：仅向
helpfulcraft-blog这一个 Bucket 上传文件），而不能触及账户内的任何其他资产阿里云提供了一键创建的功能，仅需确认即可
3. PicGo 配置与错误排查
| PicGo 设置项 | |
|---|---|
| 设定 KeyId | … |
| 设定 KeySecret | … |
| 设定存储空间名 | helpfulcraft-blog |
| 确定存储区域 | oss-cn-beijing.aliyuncs.com |
配置填写完毕后，测试上传失败，日志指出：
Error: getaddrinfo ENOTFOUND helpfulcraft-blog.oss-cn-beijing.aliyuncs.com.aliyuncs.com
aliyuncs.com 重复了两次。PicGo的“存储区域”字段不需要完整的的域名，工具会自动拼接域名
再次测试，上传成功。一个 Markdown 格式的URL自动复制到剪贴板
4. 额外探索：OSS 静态网站托管与 GitHub Pages
在探索 OSS 控制台时，我发现了“静态网站托管”的广告。我发现这似乎与我正在使用的github pages是一回事：
| 对比 | GitHub Pages | OSS 静态网站托管 |
|---|---|---|
| 思想 | 代码驱动 | 存储驱动 |
| 流程 | git push 自动触发部署 |
本地构建 -> 手动/工具同步文件 |
| 过程 | 内置 Jekyll/Actions，可处理源文件 | 无构建能力，只托管最终的静态文件 |
| 速度 | 良好 | 可与专业 CDN 深度结合 |
| 场景 | 开发者博客、项目文档 | 对访问速度有高要求的企业官网、营销页等 |
相比GitHub Pages, OSS 是一种可以自由组合的专业模块
5. 额外探索：函数计算与 Serverless
除了静态托管，我还看到 “函数计算 (Function Compute)”模块。它的描述是：“事件驱动、无需管理服务器即可运行代码”
我想起了我不久前搭建的自动化工具 Make.com 和 Pipedream
我注意到，这与函数计算在本质上似乎是相同的。经过了解，我意识到它们都属于 Serverless 架构
- Make.com: 高抽象层次的 Serverless。它们将复杂的代码逻辑封装成可视化的模块，用户只需连接它们
- 函数计算: 更底层的 Serverless。它允许用户直接编写代码，实现更灵活、更定制化的逻辑，但仍无需管理服务器
总结
- 分离原则。代码与静态资源应分离存储，让各自的系统保持轻量、高效
- 最小权限原则。永远不要在应用中使用主账户 AccessKey。应为每个应用创建拥有最小权限的 RAM 用户
- 类比学习。利用已知的概念来理解新概念，建立知识的内在联系