CloudFlare-ImgBed v2.1.0 版本发布！
经过几个月陆陆续续的更新，以及这几天的爆肝，终于把很多之前想做的功能做的七七八八了，其中有一些是我自己认为重要的功能，当然大部分还是在大家集思广益提各种issue以及和我私下沟通提及的需求，选了一些最影响体验的先行处理。
这些新功能里面最重要的有以下几点：
- 支持大文件分片上传，提高大文件上传稳定性
- Telegram Bot渠道支持分片存储，支持上传超过20MB的文件
- 支持文件数据库索引，优化访问速度
- 支持备份和恢复功能
- 支持使用API Token进行API鉴权，开放更多接口
- 管理端增加系统状态页面
- 支持 nsfwjs 审查渠道，支持自定义 API 地址
- S3 渠道支持路径风格访问方式，兼容更多 S3 兼容存储服务
完成这些功能的同时，把之前的代码进行了大量的重构和优化，对比两个月前的项目结构，已经判若两人。
其中在实现大文件上传功能时，为了应对cloudflare免费版worker的各种CPU、内存限制，在代码中采用了各种重试、延迟、同步机制，以确保能在资源限制极其严苛的情况下完成大文件的上传任务。但是，尽管已经做了大量优化，大文件上传依然无法做到 100% 的成功率。523 的报错依然时而会出现，但是这相对于很多类似项目已经具有了一定的进步。
实现数据库文件索引的初衷，是因为 cloudflare KV 的文件无法按照时间顺序列出，因此尽管后端已经实现分页操作，每次依然要先列出全部文件，再按时间序排列。这样一来文件数量达到几万量级时，会经常出现 CPU 时间超限或者运行时间超限的问题。这样的情况下，使用数据库索引似乎是一个最好的选择。
然而，由于 KV 最终一致性的设定，熟悉数据库的佬友应该知道，在更新KV时可能会出现各种读写冲突（例如不可重复度，写后读一致性无法保证等）。为了应对这些冲突，我尝试过自己设计悲观锁、乐观锁等各种方式，均因为 KV 的特点而无法奏效。最终，我想到一个新的方案，既然并发读写索引会出现各种无法避免的冲突，那我干脆不进行并发读写，而是把每一个对索引的操作存储为独立的键值对，最终在一个统一的节点全部合并到索引当中去。而这个关键的“节点”就是每次读取索引的时刻。最终，在数次重构之后，形成了现在的版本，我称每一个对索引的操作为“原子操作”（借用一下数据库中的名字，但是不保证ACID哈😂）。目前的版本基本能够按照期望处理索引的更新，但是其中难免会出现一些潜在的未考虑到的冲突，所以管理端提供了“重建索引”的选项供大家手动重建索引，维护数据库的一致性，这也算一种折衷的方案。
可能有人会问我为什么不用D1等现有数据库，我的考量是一方面会增加项目的部署难度，让项目变得更“重”；另一方面会让已经部署的用户不能实现无感更新，需要耗费更多的时间。
总而言之，在cloudflare平台上开发项目是一种完全不同的体验，在处处都要考虑服务器严苛的资源限制，做出种种折衷操作，或者是用出各式各样的奇技淫巧，还希望各位能多多支持，给个免费的star吧。ಥ_ಥ
最后，贴一个完整更新日志和项目地址吧~
Add Features:
- 支持备份和恢复功能
- 支持指定部分默认上传设置
- 支持使用API Token进行API鉴权，开放更多接口
- 支持文件数据库索引，优化访问速度
- 管理端增加系统状态页面
- 支持大文件分片上传，提高大文件上传稳定性
- Telegram Bot渠道支持分片存储，支持上传超过20MB的文件
- 文件读取支持流式处理
- 同名文件支持自动重命名
- 管理端外链图片支持预览
- 美化部分报错页面
- 增加404页面
- 登录密码增加有效性检查
- 管理端支持全局搜索
- 管理端登陆页支持自定义背景图片
- 支持 nsfwjs 审查渠道，支持自定义 API 地址
- S3 渠道支持路径风格访问方式，兼容更多 S3 兼容存储服务
Fix Bugs:
- 修复文件名包含特殊字符时的错误
- 代码风格优化
