2026-02-15 08:51:57
今天继续为大家分享一款实用的免费云存储服务——Synology C2 对象存储。该服务提供与 S3协议 兼容的对象存储能力，具备企业级的数据安全性，定价透明，并与 Synology NAS 设备深度整合，适合中小团队或企业用户搭建云存储基础设施。
更重要的是，它支持免费套餐，无需认证即可使用，每个区域提供15GB存储空间和15GB下载流量。当前可选区域共两个，总计可享30GB存储 + 30GB下载流量。
点击下方链接注册账号，也可以直接用Google邮箱快捷登录：
https://account.synology.com/en-global/register/quick/a62fb91981af4796b902b525c8b216c5?lang=en-global
注册登录后进入：https://c2.synology.com/en-global/object-storage/overview
点击【Get 15 GB for free】
控制台界面很简洁哈，直接在 Buckets 栏目中【创建桶】
创建存储桶基础信息
Bucket name 是必须的。Create Access Key 是指单独为这个存储桶创建一个访问的密钥，这里我们点击勾选方便一会使用，一定要备份记住密钥，然后点击【Next】
数据保护设置
下面的步骤就是是否开启桶的版本控制，和桶对象锁。这两项是保证数据安全的，建议开启。或者根据你自己的需求来，可以都勾选上，也可以不勾选。然后点击【create bucket】按钮。
备份密钥
创建完成会展示 Access Key ID 与 Secret Key，密钥关闭窗口后无法再次查看，务必复制或下载备份。
查看桶Endpoint
存储桶创建完成后，桶列表右侧可查看对应区域Endpoint地址：
进入桶内可创建文件夹、上传文件，支持查看历史版本、清理分片上传碎片释放空间。
每个区域的免费资源（15G存储+15G流量）需单独激活。 控制台右上角切换区域，可选：
切换未开通免费额度的区域，即可再次领取15GB存储+15GB流量，两个区域合计30GB存储+30GB下载流量；已开通区域不会再显示激活入口。
在图片上传客户端的选择上，推荐 MarSeventh 开源的 CloudFlare-ImgBed，界面简洁直观，可免费部署在CloudFlare，也支持Docker一键部署，兼容多存储后端。
不推荐PicGo/PicList原因：Synology C2桶默认私有，直链访问存在不便；替代方案还有OpenList等可自行尝试。
搭建教程可参考往期文章：用HuggingFace搭建100G超大图床
1). 进入 CloudFlare-ImgBed 系统后台，在系统设置中，点击【系统设置】->在【上传设置】中添加上传渠道。如下
2). S3渠道填写参数对照表
| 填写项 | 填写内容 |
|---|---|
| 渠道类型 | S3 |
| 渠道名称 | 自定义如：synology-1 |
| Endpoint | 创建桶的endpoint（例：https://us-004.s3.synologyc2.net） |
| 存储桶名称 | 自己创建的桶名 |
| 存储桶区域 | 对应区域标识（例：us-004） |
| 访问密钥 ID | 备份的Access key ID |
| 机密访问密钥 | 备份的Secret key |
| 容量限制 | 15GB |
| 停用阙值 | 95% |
| CDN域名 | 可选，有自有CDN可填写，加速访问 |
填写界面参考：
3). 首页上传配置
回到首页右下角【上传设置】，上传渠道选择刚刚新增的S3渠道，自定义上传目录、文件命名规则、图片压缩等参数，保存后即可拖拽粘贴上传图片。
Synology C2 对象存储免费套餐优势：
操作简单，新手也能快速上手搭建专属图床/网盘。
2026-01-18 17:20:36
今天要分享一个超级实用的黑科技教程——如何利用 HuggingFace 免费搭建一个 100G 的图床和网盘，而且全程无需实名认证，操作简单，小白也能轻松上手！
这个项目其实是一个开源的“宝藏”，名字叫 CloudFlare-ImgBed，是一个基于 Cloudflare Pages 打造的文件托管平台。它不仅完全免费，还非常稳定高效，目前在 GitHub 上已经收获了超过 4k 的 star，热度非常高！项目的作者是 MarSeventh 大佬，不得不说，这个设计真的很良心。
它支持多种存储方式，配置灵活，可以满足不同场景下的需求。无论是做图床、分享文件，还是搭建个人小网盘，都非常方便。话不多说，咱们直接进入正题，开搞！
官方文档：https://cfbed.sanyue.de/
演示站点：https://cfbed.1314883.xyz/ 访问密码：cfbed
我自己搭建的实例：https://imgbed.202090.xyz/
前台界面
后台界面
采用了前后端分离的架构：
简单来说，就是通过 Cloudflare 的强大边缘网络，把 HuggingFace 的 100G 免费存储空间利用起来，变成一个私人的图床或网盘。
作者提供了两种部署方式：一种是 Cloudflare Pages 托管（推荐，免费），另一种是 Docker 部署（适合有服务器的朋友）,本博客仅展示 Cloudflare Pages 托管方式。
首先 fork 源码仓库：https://github.com/MarSeventh/CloudFlare-ImgBed 到自己的 GitHub 。如果有更新就可以直接将更新的立马部署到 Cloudflare Pages 上。
1、在控制面板找到【计算和AI】然后点击【Worker and Pages】在页面的右上角点击【创建应用程序】，然后点击下面的想要部署 Pages？的【开始按钮】。如下图
2、在 “导入现有 Git 存储库” 处点击 “开始使用”
3、选择【CloudFlare-ImgBed】项目，然后点击【开始设置】按钮
4、项目名称自定义，然后构建命令填入： npm install ,其他默认，点击【保存并部署】
5、配置数据库
数据库用于存储文件元数据，是必需的组件，可选数据库为 KV 数据库和 D1 数据库。两者对比如下表所示，根据自己使用场景从其中选择一种配置即可。
重要提示：KV 数据库和 D1 数据库只需要配置其中一个即可，不需要同时配置两个！建议根据下表选择适合自己的数据库类型。
| 特点 | KV 数据库 | D1 数据库 |
|---|---|---|
| 读写性能 | 高 | 较低 |
| 免费额度 | 少 | 多 |
在【存储和数据库】->【workers KV】添加KV数据库，KV名称填写 img_url
如果要使用D1数据库，就在【存储和数据库】->【D1 SQL数据库】，点击右上角的【创建数据库实例】，这里就不做详细说明了。
6、将数据库绑定到项目上。
在Workers and Pages中点击刚刚部署好的项目，在面板中找到【设置】选项，点击绑定按钮，添加绑定KV数据库的信息如下。点击保存以后，项目会重新部署。
img_url
img_url
7、重新部署以后，就可以使用CloudFlare分配的域名访问了，当然建议绑定自己的域名
官方地址：https://huggingface.co
HuggingFace 渠道支持大文件直传，适合上传超过 20MB 的文件。对于大文件，系统会自动使用 LFS 协议进行分片上传。
1、注册登陆后，在控制面板新建一个新空间，空间名字自定义。
Select the Space SDK 选择 docker 的空项目或者是其他
Space hardware选择FREE版本不要钱的。空间的可见性也是根据你自己的意向选择就好了
然后点击下面的【Create Space 】按钮
2、创建 HuggingFace Access Token，在【Setting】中的【Access Tokens】中点击【Create New Token】就行了，token的名称自定义，然后勾选仓库的读写权限，如下。
1、进入CloudFlare-ImgBed系统后台，在系统设置中，点击【系统设置】->在【上传设置】中添加上传渠道。如下
2、添加一个HF存储的渠道方式，渠道名称自定义，然后仓库名称一定是 用户名/仓库名 的格式，然后填入上面申请的Acess Token信息。点击保存就行了。
3、在系统设置中，点击【系统设置】->【页面设置】中去配置默认上传渠道信息和其他的配置就行了，如下。
你也可以增加其他的上传渠道，还可以开启负载均衡！
这个方案是不是超级香？不需要实名认证，访问速度还杠杠的，最关键的是——完全免费！100G 的 HuggingFace 空间，加上 Cloudflare 的全球加速，无论是放博客图片、分享文件，还是当个人网盘，都绰绰有余。
而且全程无需自己买服务器、不用装任何客户端，只要有个 GitHub 账号和 Cloudflare 账号就能搞定。还要什么自行车？赶紧去搭建一个吧！
2025-12-14 20:53:12
在工作自评中，我们总会陷入两难：不谈缺点显得虚伪，坦诚不足又怕被否定能力。其实很多所谓的 “短板”，不过是自我要求过高、追求极致过程中产生的副作用。于是我梳理了这份特殊的自我剖析，将职场自评的痛点转化为高标准下的完美主义瑕疵，找到最得体又真实的自我表达方式。
1、工作推进偏保守，习惯于按部就班完成流程，主动突破、大胆尝试的意识不足，导致部分工作推进不够高效，创新亮点不多。
2、业务钻研不够深入，满足于把日常事务处理到位，主动钻研新流程、新方法的劲头不足，专业能力提升速度跟不上岗位要求。
3、工作思考不够靠前，多是被动落实任务，主动提前谋划、提前预判的意识较弱，对工作整体节奏把控不够精准。
4、细节把控不够严格，完成任务时更注重速度，对质量、细节打磨不够，精益求精的意识有待加强。
5、重点工作聚焦不够，日常事务占用精力较多，对核心工作的持续跟进、深度推进力度不足，成效不够突出。
6、沟通衔接不够主动，与同事、协作方的沟通多停留在事务层面，深入交流思路、共同优化工作的频次偏少，协作效率有待提升。
7、经验沉淀不够系统，做完工作后复盘梳理不及时，好的做法没有及时固化，问题没有提前规避，重复消耗精力。
8、落实力度不够扎实，安排部署后跟踪问效不够，对过程中的新情况、新问题掌握不及时，解决问题的及时性不足。
9、工作标准要求较高，有时过于追求细节完美，在统筹推进速度与质量平衡上把握不够到位，一定程度上影响了整体工作效率。
10、对待工作责任心较强，凡事习惯亲力亲为、把关到底，在合理分工、放手放权方面思考不够，导致自身精力分散、统筹压力较大。
11、工作态度较为严谨，对任务完成质量要求较高，有时容易陷入局部细节纠结，对整体工作的宏观统筹和节奏把控仍需进一步加强。
12、自我要求相对严格，习惯于对标更高标准找差距，在及时总结成绩、提炼亮点方面重视不够，工作成果展示不够充分。
2025-11-29 20:12:35
大家好，我是时光本的开发者，时光本是一款专注效率与记录的笔记工具。可以帮助你整理各种信息，包括便签、清单、图片、纪念日、地址、链接、银行卡、名片、账号、密码等。今天想和大家聊聊这款 APP 从诞生到即将下线的全过程 —— 没有什么高大上的商业计划，只是一个技术人 “折腾” 出来的小成果，以及一些想和用户说的真心话。
我本身是 iOS 端开发，2020 年的时候，主要抱着两个想法开始做这个 APP：
所以时光本从一开始就设计了两大模块：一个管 “笔记”，能存日常灵感、纪念日、银行卡信息、名片、网址这些；另一个管 “账号密码”，专门用来安全存储各类登录信息，就是想一次性解决 “记东西麻烦” 的问题。
很多人问我，个人开发一个全平台 APP 难吗？说实话，难，但难的不是写代码。
我虽然做 iOS 开发，但产品设计、UI、交互、推广这些完全是门外汉。为了让时光本 “像个正经 APP”，我逼着自己走完了完整的开发流程：
需求调研：先列了自己和身边朋友的痛点 —— 要能记密码、便签、纪念日、银行卡；要苹果多端能用；要安全不泄露数据。原型与设计：先后画了好几版原型图，最终确定各个页面的功能模块。接着学 Sketch 做 UI，为了一个简洁的 icon，改了三十多版才满意；按钮的颜色、弹窗的圆角，甚至文字的字号，都反复调过，就想让用户打开时觉得 “舒服不刺眼”。交互设计：用 Axure 模拟用户操作 —— 比如添加银行卡时，要先选卡类型再填卡号，避免字段混乱；输入密码后，要有 “隐藏 / 显示” 按钮；解锁时，指纹识别失败要弹友好提示，而不是冷冰冰的报错。这些细节，我对着自己的使用习惯改了又改，就怕用户用的时候觉得 “不顺手”。多端开发：作为iOS开发，iOS端的开发 (主要包括iCloud云同步，本地通知、远程推送，分享，统计，安全锁（指纹/面部、数字密码、图形密码），账号排序、搜索，扫一扫、证书申请、上线、谷歌广告、内购等），没遇到太大麻烦；但 MacOS 端因为涉猎较少，网上资料也较少的情况下，我只能下班和周末啃官方文档，从基础语法开始学，遇到同步 bug 时，熬夜查论坛、试代码，终于打通了 iPhone、iPad、Mac 的 iCloud 同步 —— 虽然切换设备要登 iCloud，但至少数据能无缝衔接了。测试与上线：没有测试团队，就自己测：单元测试保证每个功能不崩，集成测试确认多端同步不会丢数据，还找了十几个朋友试用，比如有朋友说 “Mac 端同步慢”，我就优化了 iCloud 的同步策略；有人说 “想给笔记分类”，我就加了标签功能。最后提交 App Store 审核时，连截图的尺寸、描述的关键词都改了五遍，终于在 2020 年 1 月 22 日上线了。上线后，我没做过什么推广，全靠用户口口相传。看到有人说 “时光本帮我记住了奶奶的生日”“再也不用怕忘银行卡密码了”，那种开心，比涨工资还爽。
其实不是时光本不好用，而是我发现了它的 “局限性”：
后来我琢磨，要是把时光本的功能移到 H5 网页端，会不会更方便？不用下载 APP，不管用什么设备，打开网页登一次密码 (之后会用缓存保持登录，除非手动登出），就能直接看数据，刚好解决了 “偶尔用但要用得顺” 的问题。
不过，H5 网页端暂时没开放给普通用户：
决定下线后，我最担心的就是用户的数据丢了。所以特意写了详细的时光本数据导出指南：
为确保数据安全，我准备了 iOS (适用于 iPhone） 和 macOS (适用于 Mac 电脑） 版本的图文导出流程，操作中若有疑问，请留言，我会协助你完成迁移 —— 毕竟，时光本里存的不是数据，是大家的回忆和重要信息，我得帮大家守好。
从 2020 年到 2026 年，时光本陪了大家六年。它不是什么爆款 APP，却有一群每天打开的忠实用户；它没有团队运营，却收到了无数暖心的反馈。
对我来说，时光本不只是一个项目，更是我作为 iOS 开发者的成长印记 —— 从只会写前端代码，到学会设计、交互、多端开发，每一步都藏在时光本的版本更新里。
虽然时光本要下线了，但我没有放弃 “做好用的记录工具” 的想法。以后不管是优化 H5，还是做新的小工具，我都会保持这份初心：做简洁、安全、真正帮到人的东西。
最后，谢谢每一位用过时光本的人。谢谢你们包容它的不完美，谢谢你们给我的反馈，谢谢你们让我的 “折腾” 有了意义。
时光本会停在这里，但我们记录生活的方式，永远不会停。
祝大家，都能找到适合自己的 “时光容器”，好好记住那些重要的人和事。
时光本内容汇总：
2025-10-03 20:51:07
本文分享一种基于对象存储+CDN的组合方案，可实现免费10G存储+无限流量的图片外链，同时配置自动水印功能，该方法理论适用于所有对象存储与 CDN 的搭配。
以又拍云存储 + 腾讯云EdgeOne为例，通过对象存储存放图片并配置图片处理规则，再借助 CDN 的 URL 重写功能，实现访问图片时自动添加水印，且无需手动给每张图片链接加后缀。此方案不仅能避免图片被盗用，还能有效控制流量成本。
1). 选择任意对象存储 (本文以又拍云为例）作为图床，可直接上传图片或通过图床程序上传。
2). 在对象存储后台找到图片处理功能，选择间隔标识符，又拍云提供 ! _ - 三种可选。
3). 创建图片处理规则，按需配置参数：
4). 点击预览按钮确认水印效果，满意后保存规则，务必记录规则名称 (如示例中的 shuiyin），后续配置会用到。
到此就可以进行实际图片测试了，比如原来的图片外链是https://img.gorpeln.top/gorpeln.png，加上前面设置的图片处理参数之后的格式就是https://img.gorpeln.top/gorpeln.png-shuiyin，这样其实还是没有达到目的，因为访问不带图片处理规则的原链接，还是没有水印效果的，想要最终实现不加参数又能加上水印，这就要去CDN加速那边设置了。
1). 进入腾讯云 EdgeOne 后台，找到图床域名对应的规则引擎。
2). 配置回源 URL 重写规则，参数设置如下：
^/(.*\.(jpg|jpeg|png|gif|webp|bmp))$ (可根据实际使用的图片格式增减后缀）
/$1-shuiyin (其中 - 为步骤 2 选择的间隔标识符，shuiyin 为步骤 4 保存的规则名称）
正则表达式： ^/(.*\.(jpg|jpeg|png|gif|webp|bmp))$ (这里加上实际使用的图片格式的后缀)
替换为： /$1-shuiyin （这里的-就是上面设置的间隔标识符，shuiyin就是上面设置的图片处理规则的名称）
很多使用对象存储的博主会因流量被刷产生高额账单，核心解决办法是做好防护配置：
2025-09-30 16:58:21
今天打开博客查看时显示异常，提示connection reset by peer。通过控制台数据回溯发现，9 月 26 日 - 9 月 30 日期间，博客流量已出现明显异常波动：访问请求量远超日常均值，且来源 IP 分散、访问行为不符合正常用户逻辑，初步判断为恶意流量攻击。所幸此前已针对博客安全做了基础防护配置 —— 开启了IP访问频率限制与流量封顶限制，所以在本次攻击中损失较小。
在检测到持续的异常流量后，CDN系统触发了安全防护机制，对博客访问进行了临时限制，但由于我此前未开启又拍云的异常事件短信/邮件提醒功能，未能第一时间收到预警，导致发现问题时已出现访问中断。截至目前，博客访问链路完全恢复，经测试各项功能均正常可用。
最后建议平时做好防护，避免出现损失：