[{"content":"","date":"2026-10-25","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"2026-10-25","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"一个喜欢折腾机器的人。\n大部分时间花在写代码、修环境和给别人的项目擦屁股上。这里算是个存档点，把踩过的坑、想清楚的事、没想清楚但想写下来的话，都放在这儿。\n写东西的原则只有一条：不确定的事就说\u0026quot;我不确定\u0026quot;，不装作知道。\n联系方式我还没想好要不要公开，先留着。\n你要是真想找人说话，可能得等我哪天把评论区或者邮箱补上——现在这个站安静得连个留言的地方都没有，挺不合理的，我知道。\n","date":"2026-10-25","externalUrl":null,"permalink":"/about/","section":"小狐API","summary":"一个喜欢折腾机器的人。\n大部分时间花在写代码、修环境和给别人的项目擦屁股上。这里算是个存档点，把踩过的坑、想清楚的事、没想清楚但想写下来的话，都放在这儿。\n","title":"关于","type":"page"},{"content":"","date":"2026-10-25","externalUrl":null,"permalink":"/tags/%E9%9A%8F%E7%AC%94/","section":"Tags","summary":"","title":"随笔","type":"tags"},{"content":"","date":"2026-10-25","externalUrl":null,"permalink":"/posts/","section":"文章","summary":"","title":"文章","type":"posts"},{"content":"这个站昨天还在我脑子里，今天就已经能打开了。\n域名是很早以前买的，一直空着。买的时候想的是\u0026quot;以后总要用\u0026quot;，然后一放就是很久。中间不是没动过念头，每次都是打开后台看一眼续费价格，关掉，继续刷手机。\n真正让我下决心的是件小事。有一次想找一份两年前写的东西，翻了几个网盘、两个文档应用，最后在一个早就忘了密码的账号里找到一段残缺的富文本——图片全挂了，代码的缩进也没了。那一刻我才意识到，把东西散落在十几个平台上，和没存其实差不多。\n于是就有了这里。\n用什么搭的\r#\rHugo，加一个叫 Blowfish 的主题。\n选它的理由很朴素：构建快，一个可执行文件，服务器上不用装 Node、不用装数据库、不用维护一堆依赖。我这台机器内存只有 1.6G，跑那些\u0026quot;大而全\u0026quot;的建站程序是真吃力。\n改动不多，无非是把主题默认的标题字号压了一档（中文标题按英文习惯给那么大，看着像在喊人），页脚补了备案信息，配色从默认换成了一个偏石色的方案。这些零碎的调整以后可能单独写。\n会写什么\r#\r大概率是技术，也可能突然写点别的。\n我不打算给自己定栏目。栏目定了就得维护，维护不动就变成一排三个月没更新的空分类，比不写还难看。\n更新频率？说实话不知道。可能连着写几天，也可能两个月没动静。这里不是给别人交差的地方，我不想给自己加这种 KPI。\n倒是有个自我约束：不确定的事就写\u0026quot;我不确定\u0026quot;。网上已经够多言之凿凿的错误了，不缺我一个。\n先把门牌挂上，剩下的慢慢来。\n","date":"2026-10-25","externalUrl":null,"permalink":"/posts/hello-muax/","section":"文章","summary":"开了个新站。不为流量，也不为展示，就是想有个自己说了算的地方。","title":"先把门牌挂上","type":"posts"},{"content":"","date":"2026-10-25","externalUrl":null,"permalink":"/","section":"小狐API","summary":"","title":"小狐API","type":"page"},{"content":"","date":"2026-10-25","externalUrl":null,"permalink":"/categories/%E6%9D%82%E8%AE%B0/","section":"Categories","summary":"","title":"杂记","type":"categories"},{"content":"","date":"2026-10-19","externalUrl":null,"permalink":"/tags/%E6%9C%8D%E5%8A%A1%E5%99%A8/","section":"Tags","summary":"","title":"服务器","type":"tags"},{"content":"有人问我这台机器上跑了什么，我说一个静态博客，对方的表情大概就是\u0026quot;那也太浪费了\u0026quot;。\n其实不浪费，只是它干的活跟你想象的不一样。\n先说数字\r#\r开机之后 free -m 是这样：\ntotal used free shared buff/cache available Mem: 1613 430 270 2 1080 1182 Swap: 0 0 0\r标称 2G，实际可用 1613M，差的那些是内核和保留区。已经用了 430M，这里面包括系统本身、SSH、几个监控 agent，以及 Caddy。\nCaddy 单独看，ps 显示的常驻内存是 38M 左右。它同时在跑 HTTP/1.1、HTTP/2、HTTP/3，还管着两张证书的自动续期，38M 我觉得挺客气了。\n磁盘 40G，现在用掉 3G，其中整个站点的产出物是 540K。\n它擅长什么\r#\r静态博客本质上就是个文件服务器。请求进来，找文件，发出去。没有数据库查询，没有模板渲染，没有 PHP-FPM 之类的常驻进程。CPU 基本闲着，负载常年在 0.0x。\n这种\u0026quot;只读型\u0026quot;的服务是 2 核小机器最舒服的场景。哪怕突然来一波流量，它也只是把文件往网卡里塞，塞不动的时候瓶颈在带宽，不在 CPU。\n反过来说，有几件事我不建议在这上面做：\n跑数据库。MySQL 在默认配置下就能吃掉几百兆，再配上应用，1.6G 立刻见底，然后开始 OOM，然后你半夜被叫起来。 在这台机器上编译。Hugo 构建很快，但那是几万个文件读写的活，小机器的 IO 和内存都不占优势。我干脆在本地构建，服务器只接收成品，540K 传上去就完事。 同时跑好几个重型服务。JVM 那类东西起步就是几百兆，两个就把内存吃干净了。这不是它的错，是选错了工具。 \u0026ldquo;够用\u0026quot;是个被低估的词\r#\r买机器的时候很容易陷入一种思路：先按最坏情况买，将来总会用上。结果钱花了，资源常年空着，还要为它做安全加固、打补丁、看监控。\n我的看法比较土：先想清楚这台机器要负责什么，按它的实际工作去买。真要扩容，加配置比迁移数据容易得多。\n这台 1.6G 的小机器，现在扛着一个每天可能只有几十个人访问的博客。这个负载对它来说接近于静止。真正花时间的不是它，是我——写东西、改样式、想标题。\n所以别问 2 核 2G 够不够。先问你要它干什么。\n","date":"2026-10-19","externalUrl":null,"permalink":"/posts/small-server/","section":"文章","summary":"很多人觉得 2 核 2G 是\"最低配\"，只能凑合。我倒是觉得，只要你想清楚它要干什么，它能干的事比想象中多。","title":"一台 2 核 1.6G 的机器能干什么","type":"posts"},{"content":"","date":"2026-10-19","externalUrl":null,"permalink":"/tags/%E8%BF%90%E7%BB%B4/","section":"Tags","summary":"","title":"运维","type":"tags"},{"content":"","date":"2026-10-19","externalUrl":null,"permalink":"/categories/%E6%8A%98%E8%85%BE/","section":"Categories","summary":"","title":"折腾","type":"categories"},{"content":"这台机器是 200Mbps 带宽。\n听起来很唬人。200Mbps 折算下来是 25MB/s，理论上一个 500MB 的文件二十秒传完。买的时候我也觉得挺爽，后来算了一笔账，发现这个数字跟我实际干的事几乎没关系。\n先看看一个页面多重\r#\r我把首页拉下来量了一下，开了 gzip 之后 HTML 是 5.7KB，主样式表 20.7KB，脚本十来个 KB，加起来四十 KB 出头。文章页会多一些，但也基本在这个量级——除非你放高清大图，那是另一回事。\n也就是说，25MB/s 的带宽，理论上每秒能送出六百多个这样的页面。\n六百。我现实里的日访问量，用一只手数都嫌多。\n那瓶颈在哪\r#\r真正常见的瓶颈，按我的经验大概排这个顺序：\n第一是 DNS 和 TLS 握手。用户点开链接，先查 DNS，再握手，再协商证书，这一圈走完，几百毫秒就没了。带宽再大，也省不下这段时间。\n第二是线路和运营商互联。机房在杭州，访问者在成都、在广州，走的路径不一样，跨网的时候容易绕路。这不是你买多少兆能解决的，属于玄学范畴。\n第三才是带宽。而绝大多数个人站的流量，连 10Mbps 都用不满。\n所以我买的 200Mbps，本质上是给\u0026quot;万一来一波流量\u0026quot;这件事交的保险费。问题是，我这种站，来一波流量的概率跟中彩票差不多，真中了我也更该高兴才对。\n一个更现实的算法\r#\r假设哪天真的火了，一万个人同时在线看文章。按每人 40KB 算，总传输量 400MB，平均分摊到几秒钟里，需要几十兆每秒——这时候带宽才开始有意义。\n而在那之前，你更需要担心的其实是 CPU：每来一个 HTTPS 连接，都要做一次握手运算。2 核的机器在这个环节的上限，通常比带宽先到。\n说白了，带宽是最容易被营销的指标。它是个大数字，好写进广告词，也好看。真正决定体验的东西——DNS 解析速度、CDN 有没有、图片压没压、样式表多大——全都藏在这些数字后面。\n我不是劝你别买带宽。我是想说，买完之后别对着它产生幻觉，觉得站快了，其实站快不快你根本没测过。\n顺便说一句，我现在这套东西真正的开销是：一个月十几块钱的机器，加一个域名，加一下午的配置时间。带宽那一栏，是我最不关心的部分。\n","date":"2026-10-14","externalUrl":null,"permalink":"/posts/bandwidth-illusion/","section":"文章","summary":"带宽数字是最容易让人安心、也最容易买多的东西。算完这笔账我发现，我买的其实是个心理安慰。","title":"200Mbps 到底买的是什么","type":"posts"},{"content":"","date":"2026-10-14","externalUrl":null,"permalink":"/tags/%E5%B8%A6%E5%AE%BD/","section":"Tags","summary":"","title":"带宽","type":"tags"},{"content":"我最近在帮人挑几个工具，连着点开十几家产品的官网，看到第七个的时候我停下来了。\n因为它们长得几乎一模一样。\n深色底，中间一团蓝紫渐变的光，标题用白色无衬线大字，右上角一个\u0026quot;Get Started\u0026quot;，页面上浮着几个带玻璃拟态边框的卡片。往下滚，三栏功能点，每栏一个线性图标。\n我不是说这样丑。单看一个，确实还行，至少不会出错。问题是当你一天里看到十次同样的东西，它就从\u0026quot;高级感\u0026quot;变成了\u0026quot;模板味\u0026quot;。\n为什么会变成这样\r#\r我想了想，觉得原因不难猜。\n渐变这东西便宜。你不需要懂版式、不需要找好图、不需要控制留白，只要调两个色值拉一条线性渐变，画面立刻就\u0026quot;有内容了\u0026quot;。它还是个特别好用的遮羞布——背景够花，就没人注意你标题和正文的字号差了一倍。\n再加上 AI 产品扎堆，行业的视觉语言互相抄，半年就抄成了一种公约数。蓝紫之所以胜出，大概因为蓝色显得可信、紫色显得智能，合起来就是\u0026quot;既可靠又先进\u0026quot;，翻译成人话就是\u0026quot;我也不知道该表达什么\u0026quot;。\n我自己偏爱什么\r#\r说几个我明确喜欢的做法。\n一个克制的强调色。 全站只用一种颜色做点缀，链接、按钮、当前状态。剩下的全是黑白灰。颜色越少，那个颜色越有分量。\n字重和字号撑起层级。 标题大、正文适中、注释小，靠这个就能分清楚主次，不需要给每块内容加不同的底色和边框。\n留白敢留。 很多人怕空，觉得空就等于没设计完。其实一块内容周围有足够的空白，读者自然知道这里是重点。\n别什么都要动。 链接悬停变色就够了，别再放大、别再发光、别再位移三像素。动效多不是精致，是心虚。\n这个站\r#\r这个站用的是个现成的主题，配色是石色系加一点柠檬绿。\n选它不是因为多有设计感，恰恰相反——它足够安静，安静到你可以专心看字。我做的事只有两件：把标题字号压小，把页脚收拾干净。\n顺便，我也不太喜欢满屏圆角加大阴影。卡片浮起来的效果，第一眼挺好看，第二眼你就会发现所有东西都在飘，没有东西是\u0026quot;实的\u0026quot;。\n审美是会疲劳的。今天大家觉得高级的东西，两年后就是\u0026quot;那几年那批网站\u0026quot;的通用长相。所以我的建议不是\u0026quot;别用蓝紫渐变\u0026quot;，而是——如果所有人都这么做，你至少该想一想为什么。\n大部分时候，答案是：因为省事。\n","date":"2026-10-08","externalUrl":null,"permalink":"/posts/stop-blue-purple/","section":"文章","summary":"打开十个新产品官网，八个长得像同一个模板。我不是反对渐变，我是反对所有人用同一个渐变。","title":"别再给我蓝紫渐变了","type":"posts"},{"content":"","date":"2026-10-08","externalUrl":null,"permalink":"/tags/%E8%AE%BE%E8%AE%A1/","section":"Tags","summary":"","title":"设计","type":"tags"},{"content":"","date":"2026-10-08","externalUrl":null,"permalink":"/tags/%E5%AE%A1%E7%BE%8E/","section":"Tags","summary":"","title":"审美","type":"tags"},{"content":"","date":"2026-10-08","externalUrl":null,"permalink":"/categories/%E5%90%90%E6%A7%BD/","section":"Categories","summary":"","title":"吐槽","type":"categories"},{"content":"","date":"2026-09-30","externalUrl":null,"permalink":"/tags/%E5%A4%87%E4%BB%BD/","section":"Tags","summary":"","title":"备份","type":"tags"},{"content":"我在这件事上拖过很久。\n不是因为不会。恰恰是因为太简单了——简单到总觉得\u0026quot;明天弄\u0026quot;，然后明天变成下个月，下个月变成\u0026quot;等换新硬盘的时候一起弄\u0026quot;。\n真正让我动手的是一次很小的意外：某次清理目录，rm -rf 后面少打了个斜杠，一个项目的两年历史没了。不算致命，因为代码在远端仓库还有一份。但那个瞬间我出了一身冷汗——如果那是照片呢？如果那是我手写的笔记呢？\n一个够用的原则\r#\r备份这件事，网上有个流传很久的原则，大意是：三份副本，两种介质，一份异地。\n我觉得不用背，理解意思就行：别让同一次事故能同时干掉你家所有的数据。硬盘坏、误删、勒索软件、房子漏水——这几种事发生的范围和方式完全不一样，你的副本至少要能挡住其中大多数。\n具体到我这儿：\n日常文件在本地硬盘； 重要的同步一份到移动硬盘，定期插上； 最要紧的那一小部分（笔记、文档、项目源码）再传一份对象存储或者远端仓库。 顺序有讲究。越往下，成本越高、频率越低，但也越不可能跟本地一起没。\n比备份更重要的是\u0026quot;恢复\u0026quot;\r#\r这一点我以前没当回事。\n备了三年，从来没试过还原一次。这种情况比没有备份更危险——因为你会有虚假的安全感，还会在出事的时候才发现打包脚本有问题、文件其实压根没传上去、压缩包是 0 字节。\n所以现在我给自己加了一条：每隔一段时间，从备份里随手抽一个文件恢复出来，打开看看内容对不对。\n不用多复杂，抽一个就够。这个动作花不了三分钟，但它能立刻告诉你备份到底是活的还是死的。\n文本的好处\r#\r意外之后我更喜欢纯文本了。\nMarkdown、代码、配置文件，这些不依赖任何特定软件的格式，十年后拿记事本也能打开。同步、diff、版本控制全都有现成工具，出错了也看得见。\n反过来，那些存在某个应用里的\u0026quot;富内容\u0026quot;，格式不透明，导出功能往往还是残的（付费才能导出全部，这种设计你肯定见过）。你把东西存进去的时候很舒服，想拿出来的时候才发现门是单向的。\n这个博客也一样。所有文章都是 .md 文件，放在本地目录里，哪天这个站不做了，整个目录拷走就完了。反而是那些\u0026quot;存在平台里\u0026quot;的博客，一旦平台改规则、涨价、或者关停，你的东西就在别人的硬盘上，按别人的心情保存。\n最后\r#\r备份这件事没有做完的一天，只有\u0026quot;最近一次验证是什么时候\u0026quot;。\n如果你现在回想一下，想不起来上次验证是什么时候——那就现在抽一个文件恢复一下。三分钟，比什么都强。\n","date":"2026-09-30","externalUrl":null,"permalink":"/posts/backup/","section":"文章","summary":"备份最大的问题不是没有方案，是你以为你有。","title":"备份这事，别再往后拖了","type":"posts"},{"content":"","date":"2026-09-30","externalUrl":null,"permalink":"/categories/%E9%9A%8F%E6%89%8B%E8%AE%B0/","section":"Categories","summary":"","title":"随手记","type":"categories"},{"content":"搭这个站花了一个下午。\n装 Hugo，拉主题，改配置，传上去，配好证书。中间踩了两个坑——主题要求的版本、页脚的自定义——都在半小时内解决了。这种活有明确的目标，报错了就去查，查完就通，整个过程有掌控感，很爽。\n写第一篇才是硬仗。\n我卡在哪\r#\r第一版写了大概两千字，写的是\u0026quot;为什么需要个人博客\u0026quot;。写完之后我自己读了一遍，感觉像在念一份宣言：结构工整，逻辑清晰，每段都能单独摘出来当金句。\n然后我把它删了。\n因为它不像我说话。我在群里跟人聊天的时候不会这么讲话，不会\u0026quot;首先\u0026quot;\u0026ldquo;其次\u0026quot;地排比，也不会在结尾升华一句\u0026quot;让我们共同期待\u0026rdquo;。\n第二版我换了个办法：先不管结构，想到哪写到哪，把真实的细节写下来——\u0026ldquo;打开后台看一眼续费价格，关掉，继续刷手机\u0026rdquo;。写完再看，这段话比前面两千字的宣言都像活的。\n几条还在摸索的规矩\r#\r写具体的，别写宏大的。 \u0026ldquo;互联网改变了我们的生活方式\u0026quot;这种句子，删掉不心疼。换成\u0026quot;我上次找一份笔记，翻了三个网盘\u0026rdquo;，立刻就有人信。\n形容词是偷懒。 想说一个东西难用，不要写\u0026quot;体验极差\u0026quot;，写清楚你到底点了哪里、发生了什么、你觉得哪里不对。形容词省下来的力气，最后都要用可信度还回去。\n允许不完整。 一篇文章能说清一件事就够了。我以前总想在一篇里把相关问题全铺开，结果每个点都浮在表面。现在宁可只讲一个，剩下的留着下次说。\n别为了更新而更新。 这是最容易破的一条。空分类看起来难看，但硬凑出来的水文更难看，而且骗不过读者。\n一个副作用\r#\r开始认真写字之后，我看别人文章的眼光变刁了。\n以前看到一篇条理清晰的长文，第一反应是\u0026quot;厉害\u0026quot;。现在会先看里面有没有具体的、可验证的东西。很多看着很满的文章，抽掉比喻和转折词，剩下的其实只有一句结论。\n这也算是个提醒：写不出来的时候，往往不是表达能力不够，是没什么可说的。这时候应该去干活，而不是坐在那儿憋。\n憋出来的东西，读者看得出来。\n","date":"2026-09-21","externalUrl":null,"permalink":"/posts/writing-is-harder/","section":"文章","summary":"搭这个站花了一个下午，写第一篇用了整整一周，最后还是删了重写。","title":"写字比搭站难","type":"posts"},{"content":"","date":"2026-09-21","externalUrl":null,"permalink":"/tags/%E5%86%99%E4%BD%9C/","section":"Tags","summary":"","title":"写作","type":"tags"}]