@这是一个名字 #51 方案的设计分为前置B2和R2临时存放，正式永久存在是 Github，并且在 Gitlab 上做镜像。最后用 CF cache 方案做加速。考虑到文件在保证安全的前提下不冗余。所以一开始并没有设计向全部平台无差别的存放，因为那样太占地方了，而且比现在方案差---我并不想把文件长期存放在资源有限的 R2 和 B2。 当然还有个技术的问题，不同平台的读取文件，请求文件相对容易做。但 S3 是使用 AWS CLI 上传和下载的。现在我都是用 PicGO、盘络上传等工具处理上传。我不确认在 worker 上是否能处理，我估计因为超时的问题而不行，即使可以，也没有必要重复造车了。 实际使用中，如果是图片类文件，我都跳过前置放到 R2 和 B2，直接放在 Github 了。
看懂了 还是太复杂了 不过好在一点成本都没有 完全白嫖大善人的服务 我有个疑问就是 Github封号咋办？而且全部采用cloudflare的cdn 哪怕是缓存了 大陆的访问速度也不是极速的 不过稳定性肯定是比带数据库的图床程序强得多 也不担心被刷 但我还是觉得minio更强 而且集群做出来也很稳 速度也能超越cf 就是需要投入成本 考虑到我对图片是按喜好手动决定原图还是压缩 综合来看 这种方案并不能让我满意
@Lian #57 在视频里也提到，谷歌里也查不到有 GitHub 用户因为存放文件被封号的，即使当图库也找不到前例。只有嫖学生包被封的。即使封号，也有镜像备份 Gitlab 库，一一对应的。 因为图片上传时都改为 webp 格式了，而且使用了 CF 家的 cache，我体验的话速度还是很可以的。 图片是原图还是压缩，我是在 PicGO 里设置的，博客使用就全部压缩为 webp 的了。 minio我没有用过，不过如果不考虑成本这个因素，当然专业的 OSS 更好啦，不用那么麻烦，直接买服务。本方案适合有点基础、喜欢白嫖的用户，毕竟有 Github / Gitlab / Cloudflare R2 / Backblaze B2 桶通通用来服务。
不知道能不能做个 /upload 上传文件接口，同时向多个存储上传文件。这样是不是就不用跑GitHub的Actions任务了？
mark 学习起来
@这是一个名字 #51 方案的设计分为前置B2和R2临时存放，正式永久存在是 Github，并且在 Gitlab 上做镜像。最后用 CF cache 方案做加速。考虑到文件在保证安全的前提下不冗余。所以一开始并没有设计向全部平台无差别的存放，因为那样太占地方了，而且比现在方案差---我并不想把文件长期存放在资源有限的 R2 和 B2。
当然还有个技术的问题，不同平台的读取文件，请求文件相对容易做。但 S3 是使用 AWS CLI 上传和下载的。现在我都是用 PicGO、盘络上传等工具处理上传。我不确认在 worker 上是否能处理，我估计因为超时的问题而不行，即使可以，也没有必要重复造车了。
实际使用中，如果是图片类文件，我都跳过前置放到 R2 和 B2，直接放在 Github 了。
做了个 /delete?file=<文件名> 接口，用于在 GitHub / GitLab / R2 / B2 各个节点上删除指定的文件
mark 学习起来
picgo安装不了compress插件怎么办 试了很多方法问ai用的方法也没用
看懂了 还是太复杂了 不过好在一点成本都没有 完全白嫖大善人的服务
我有个疑问就是 Github封号咋办？而且全部采用cloudflare的cdn 哪怕是缓存了
大陆的访问速度也不是极速的 不过稳定性肯定是比带数据库的图床程序强得多 也不担心被刷
但我还是觉得minio更强 而且集群做出来也很稳 速度也能超越cf 就是需要投入成本
考虑到我对图片是按喜好手动决定原图还是压缩 综合来看 这种方案并不能让我满意
@Lian #57
在视频里也提到，谷歌里也查不到有 GitHub 用户因为存放文件被封号的，即使当图库也找不到前例。只有嫖学生包被封的。即使封号，也有镜像备份 Gitlab 库，一一对应的。
因为图片上传时都改为 webp 格式了，而且使用了 CF 家的 cache，我体验的话速度还是很可以的。
图片是原图还是压缩，我是在 PicGO 里设置的，博客使用就全部压缩为 webp 的了。
minio我没有用过，不过如果不考虑成本这个因素，当然专业的 OSS 更好啦，不用那么麻烦，直接买服务。本方案适合有点基础、喜欢白嫖的用户，毕竟有 Github / Gitlab / Cloudflare R2 / Backblaze B2 桶通通用来服务。
@李喜 #56 我倒没有遇到这个问题，是compress-next那个，你认认有没有错
@fscarmen #59 现在这个作者不叫李宗林变成一个英文字面的 然后我去一直安装安装不了