写文章，永远得靠真诚
突然有种感悟，靠真情实感写文章，不知不觉就写了几千字，但是像学校里写作文那种，凑字数也才勉强凑到六七百字。 怪不得：艺术来源于生活 贴一句我很喜欢的话： 我们可以不美丽，但我们健康。 我们可以不伟大，但我们庄严。 我们可以不完满，但我们努力。 我们可以不永恒，但我们真诚。
Pages服务的共同原理
如果你用过GitHub Pages、Vercel、Netlify或者Cloudflare Pages，大概会有一种相似的体验：把代码推到Git仓库，几分钟后一个网站就上线了，附带域名和HTTPS，整个过程不需要自己配置服务器，也不需要登录什么云控制台去上传文件。 这种体验背后，几家平台的做法其实高度一致。理解了这个共同原理，也就明白了为什么它们被称为“现代前端的基础设施”。 整个流程可以分成四个环节。 第一个环节是触发。你在本地写完代码，执行git push，代码被推送到远程仓库。仓库那边配置了一个Webhook，推送成功的瞬间会向Pages平台发送一个HTTP请求，告诉它“有代码更新了”。Pages平台收到这个信号，就开始准备干活。 第二个环节是构建。平台会启动一个临时的容器环境，在里面拉取你的代码，然后根据你的项目配置执行构建命令。如果是React项目，可能是npm run build；如果是Vue项目，也可能是类似的命令。构建过程的本质是把源代码转化成浏览器可以直接运行的静态文件——HTML、CSS、JavaScript。这个临时环境用完就会销毁，所以每次构建都是干净的、隔...
qwq
为什么放假比上学还要累qwq
探究不同CDN的缓存原理
今天闲着没事，点开F12分析下我的网站，都知道我在Cloudflare上开了一份，Github pages上也开了一份，可是，我发现了不一样的地方 我发现，在Github pages上的只有第一次加载慢一点，后面几次几乎都是秒开；而在Cloudflare上的速度一直很快 我打开F12，准备看一看 ①Github pages版本我发现了问题第一次访问状态码是200 OK，而后面几次秒开，但状态码变成了304 Not Modified共发出0.3KB数据，有0.1KB回源到服务器，而剩下0.2KB是不蒜子的统计查了一下资料，大概是强缓存了整个首页 ②Cloudflare版本每一次都是200 OK，但结合我之前这篇：https://i.101229.xyz/2026/08/05/2026-08-05-07/彻底坐实了Cloudflare只强缓存JavaScript，CSS以及图片，对于经常变动的html文件缓存不深还有它在我的页面里嵌入了统计脚本，通过这一点让我们得以在DashBoard中查看统计信息。 总结根据以上信息，可以得知Cloudflare更注重内容的更新，Github更注重...
迷途
现在的话，也不知道该干什么， 有种失落，却不知道失落在哪的感觉， 就很烦， 不过我现在倒有一些想法，把领的免费域名尽量的给他清空或者少用，否则管理起来真的很头疼。时间和精力才是最大的成本 以及专心经营这个博客，分享分享日常。 如果以后没有时间，那我也会尽量做到一周或两周更新一次虽然说都是水文章，但至少能坚持。 毕竟一件事是否存在意义是因人而异的 主要是没有什么新的想法，也不想再继续试错了，现在越来越忙 算了，不管了，只要能继续前进，就好
折腾hugo博客框架
昨天晚上我突发奇想能不能首页根目录放HTML代码，然后再搞一个框架，指定它的URL为/post？这样的话混合架构，没准自由度会更高一点 但是今天试了一下，一堆报错，算了吧 之后我再折腾一下all in boom 折腾的时候我用的是hugo，毕竟，它以构建速度快而闻名 虽然说之前的那个折腾失效了，但我还安装了这个工具，我就试试搞一个更为轻量的，构建更快的博客 我看到了amigo框架，长得很像朋友圈，简单修改一下，我就构建成功了 就是这个相对路径问题太恶心了。还有hugo生成文章的时候，还必须要把TRUE改成FALSE，否则会视为草稿根本加不进去，这一点也太坑了，不过其他都还好 现在搞了一个比较轻量的小博客，可以用来写一些简短的句子 当然，现在这个博客肯定不会放弃，因为简单易用 反正两个地方我都会更新 你可以在这里体验：https://1f.cc.cd/同时已经开源，欢迎访问我的Github仓库 对了，为了这个功能，课程表已经迁移到 https://1f.cc.cd/class
雨天
一连几天都在下雨 雨断断续续
太可恶了
这个升学e网通，每天都要看好几节课 还不能摸鱼，不能挂机