https://gv.cx/posts/small-vps-health-check/ https://gv.cx/posts/small-vps-health-check/ Wed, 08 Jul 2026 11:05:00 +0000 服务器不一定要复杂维护，先把入口、服务、更新和备份看清楚，心里就会稳很多。 https://gv.cx/posts/writing-before-polish/ https://gv.cx/posts/writing-before-polish/ Wed, 08 Jul 2026 11:05:00 +0000 一篇文章最早的价值，常常不是漂亮，而是把那一点刚出现的想法留住。 https://gv.cx/posts/small-checklists/ https://gv.cx/posts/small-checklists/ Wed, 08 Jul 2026 11:05:00 +0000 清单不是为了把生活变成流程，而是给重复出现的事情留一条稳一点的路。 https://gv.cx/ Recent content on 生活笔记 Hugo -- gohugo.io zh-cn Wed, 08 Jul 2026 11:05:00 +0000 https://gv.cx/posts/embed-code-browser-in-blog/ Tue, 07 Jul 2026 16:09:00 +0000 https://gv.cx/posts/embed-code-browser-in-blog/ 写技术文章时，代码片段很容易变成孤立的证据。读者看见一个函数，却不知道它从哪里被调用；看见一个配置，却不知道它服务于哪条路径。代码本身没有错，但上下文丢了，理解成本就会被转移给读者。 更好的方式，是让文章里的代码像一个很小的项目一样被浏览。读者可以先看入口文件，再切到路由、缓存、说明文档。这样代码不是被拆碎展示，而是保留了结构。 下面这个内嵌代码浏览器展示了一个极小的请求处理流程。它没有依赖前端框架，只用 HTML 和 CSS 做文件切换。重点不是炫技，而是让一篇文章能同时承载解释和代码结构。 mini-service src/main.ts src/router.ts src/cache.ts README.md src/main.ts import { createServer } from "node:http"; import { routeRequest } from "./router"; const server = createServer(async (request, response) => { const result = await routeRequest(request); response.writeHead(result.status, { "content-type": "application/json; charset=utf-8", }); response.end(JSON.stringify(result.body)); }); server.listen(3000, () => { console.log("mini-service listening on http://localhost:3000"); }); src/router.ts import type { IncomingMessage } from "node:http"; import { remember, read } from "./cache"; type RouteResult = { status: number; body: Record<string, unknown>; }; export async function routeRequest( request: IncomingMessage, ): Promise<RouteResult> { if (request. https://gv.cx/posts/debugging-is-a-design-skill/ Tue, 07 Jul 2026 00:00:00 +0000 https://gv.cx/posts/debugging-is-a-design-skill/ 很多人把调试看成编码之后的补救动作：功能写完了，发现不对，再开始找问题。这个理解太窄了。真正高效的调试能力，往往在写代码之前就已经开始了。 一个容易调试的系统，通常有几个共同点：边界清楚、状态可见、失败路径明确、日志能回答问题。反过来，如果一个模块输入输出含混、错误被吞掉、关键状态只能靠猜，那么调试就会变成漫长的试错。 我越来越倾向于把“以后怎么排查”当成设计的一部分。写接口时，先想清楚调用方出了错会看到什么；处理异常时，先想清楚日志里需要留下哪些上下文；设计状态机时，先想清楚每一次状态变化能不能被追踪。 一个很实用的习惯是：遇到 bug 时，不只是修掉当前问题，还要问一句：“为什么这个问题没有更早暴露？”如果答案是缺少测试，就补测试；如果答案是日志不够，就补日志；如果答案是抽象太绕，就考虑拆开。这样每次调试都会让系统变得更容易维护。 调试能力的上限，不只取决于你有多熟悉工具，也取决于代码是否愿意告诉你真相。好的工程设计，应该让问题尽快浮出水面，而不是把错误藏在层层封装后面。 https://gv.cx/posts/technical-debt-is-a-decision/ Tue, 07 Jul 2026 00:00:00 +0000 https://gv.cx/posts/technical-debt-is-a-decision/ “技术债”这个词被用得太宽了。有时候它指临时方案，有时候它指历史包袱，有时候它只是大家不喜欢的一段代码。概念太宽之后，讨论就容易失焦。 我更愿意把技术债定义成一种有代价的工程决策：为了当前收益，接受未来需要偿还的复杂度。这样看，技术债不一定是坏事。赶上线、验证市场、应对紧急故障时，团队可能主动选择一个不完美但足够有效的方案。 问题不在于借债，而在于不记录、不评估、不偿还。如果一个临时方案没有写清楚为什么存在，过几个月后它就会变成没人敢碰的历史逻辑。如果债务没有还款计划，它就会持续吃掉开发速度。 处理技术债可以从三个问题开始：它现在造成了什么具体成本？不处理会影响哪些后续工作？有没有一个足够小的偿还步骤？只要能回答这些问题，技术债就从抱怨变成了可管理的工程事项。 不是所有债都值得马上还。有些代码虽然不好看，但很少变化，也没有线上风险，优先级可以低一些。相反，那些频繁修改、容易出错、阻塞新功能的地方，才是高价值的偿还对象。 技术债的管理，本质上是在业务速度和系统可持续性之间做取舍。成熟的团队不是没有技术债，而是知道自己借了什么、为什么借、什么时候还。 https://gv.cx/posts/logs-are-product-features-for-developers/ Tue, 07 Jul 2026 00:00:00 +0000 https://gv.cx/posts/logs-are-product-features-for-developers/ 日志经常被当成附属品：代码写完了，随手打几行。等线上出问题时，大家才发现日志要么太少，要么太吵，要么只有一句“failed”，没有任何能帮助定位的信息。 我更愿意把日志看成写给开发者和运维人员的产品功能。它的用户不是终端用户，而是未来那个在凌晨排查问题的人。既然是产品功能，就应该考虑使用场景：谁会看它？在什么情况下看？需要用它回答什么问题？ 一条好日志通常包含三个部分：发生了什么、相关上下文是什么、系统接下来怎么处理。比如只写“支付失败”价值有限；如果能带上订单号、支付渠道、错误码、重试状态，就能明显减少排查成本。 日志也不是越多越好。噪音太大的日志会掩盖真正重要的信号。普通流程可以用 debug 或 info，异常路径要有清晰的 warn 或 error。真正需要报警的错误，更应该和监控指标配合，而不是指望人一直盯日志。 还有一个容易忽视的点：不要在日志里泄露敏感信息。密码、token、完整身份证号、银行卡号都不应该直接出现。日志一旦进入集中系统，传播范围通常比业务数据库更难控制。 好的日志能让系统在出问题时保持可解释。它不能替代测试和监控，但它能显著缩短从“知道坏了”到“知道为什么坏了”的距离。 https://gv.cx/posts/small-refactors-pay-off/ Tue, 07 Jul 2026 00:00:00 +0000 https://gv.cx/posts/small-refactors-pay-off/ 很多团队谈到重构时，会想到一次大规模的目录调整、架构迁移或者框架替换。这样的重构成本高、风险大，也很难排进业务节奏。实际上，更常见也更可持续的是小重构。 小重构不追求一次性解决所有问题，而是在日常开发中顺手减少局部复杂度。比如把重复的条件判断提成函数，把含糊的变量名改清楚，把过长的方法拆成几个有明确意图的步骤，把散落的常量收拢到一个位置。 这些改动看起来不起眼，但它们会改变代码库的摩擦力。代码越清楚，下一次改动越容易；下一次越容易，团队越敢持续改进。长期看，小重构是在给未来的开发速度存款。 做小重构有一个前提：控制范围。最好围绕当前正在修改的功能点展开，不要顺手把半个系统都整理一遍。每次提交都应该能解释清楚：我为什么改这里，它如何降低当前或近期的维护成本。 测试也很关键。没有测试保护的重构，很容易变成“看起来更干净，但不知道有没有坏”。如果现有测试不足，可以先补一两个覆盖关键行为的测试，再调整内部结构。 小重构的价值在于它不需要等待一个完美时机。每次让代码更清楚一点，系统就更容易被理解一点。工程质量往往不是靠一次大动作建立的，而是靠很多次克制、具体、可验证的小改动积累出来的。 https://gv.cx/posts/code-review-that-actually-helps/ Tue, 07 Jul 2026 00:00:00 +0000 https://gv.cx/posts/code-review-that-actually-helps/ Code Review 最怕变成格式检查，也怕变成主观审美比赛。真正有价值的 Review，核心不是证明谁写得更好，而是提前发现风险。 我通常会先看行为，再看结构，最后看风格。行为层面最重要：这个改动是否真的满足需求？有没有破坏已有路径？异常情况怎么处理？边界输入会不会出问题？如果这些问题没看清，纠结变量名往往意义不大。 结构层面关注的是后续维护成本。比如这个逻辑是不是放在了合适的位置，是否把领域规则散落到了多个文件，是否引入了难以测试的全局状态。Review 时不一定要追求完美抽象，但要避免让下一次修改变得明显更难。 风格层面也重要，但应该尽量自动化。格式、排序、简单 lint 规则交给工具，不要让人肉 Review 消耗在这些地方。人的注意力应该留给工具不擅长判断的部分：业务语义、风险、可读性和长期演进。 一个好的 Review 评论应该具体、可操作。比如“这里看起来不太好”没有太多帮助；“这个分支里 userId 为空时会跳过权限校验，是否需要返回 401？”就能推动问题被解决。 Code Review 的目标不是把代码改成自己的写法，而是让这次变更更可靠。保持这个目标，讨论会少很多情绪，多很多工程质量。 https://gv.cx/posts/first-day/ Mon, 06 Jul 2026 00:00:00 +0000 https://gv.cx/posts/first-day/ 今天把个人生活博客搭了起来。 这个站点会尽量保持简单：文字为主，方便写，方便维护，也方便以后迁移。可以记录日常、旅行、照片说明、读书笔记，或者任何不想只留在聊天软件里的片段。 下一步可以把这篇示例文章替换成真正的第一篇记录。 https://gv.cx/posts/morning-walk/ Sun, 05 Jul 2026 08:20:00 +0000 https://gv.cx/posts/morning-walk/ 今天起得比平时早一些，出门的时候街上还很安静。早餐店刚把蒸笼摆出来，路边的树叶上还有一点水汽。 走到街角时，阳光正好从楼缝里照下来。没有特别的事情发生，只是觉得这种没被安排满的早晨很难得。 回来的路上买了一杯热咖啡，顺手记下这几行。以后也许会发现，生活里值得留下的很多瞬间，其实都很普通。 https://gv.cx/posts/late-night-desk/ Sat, 04 Jul 2026 23:40:00 +0000 https://gv.cx/posts/late-night-desk/ 晚上把书桌收拾了一遍。键盘、杯子、便签、充电线，每一样东西都有自己的位置以后，整个人也跟着安静下来。 最近发现，环境会影响很多细小的决定。桌面乱的时候，打开电脑就想逃避；桌面干净的时候，写几句话也变得容易。 整理不一定能解决问题，但至少能给明天留一个比较清爽的开始。 https://gv.cx/posts/weekend-market/ Fri, 03 Jul 2026 10:10:00 +0000 https://gv.cx/posts/weekend-market/ 周末去了趟菜市场。本来只是想买点水果，结果绕了一大圈，最后多买了青菜、鸡蛋和一袋很香的花生。 菜市场总是很有生命力。有人讨价还价，有人熟练地挑菜，有人推着小车慢慢走。所有声音混在一起，反而让人觉得踏实。 回家路上拎着东西，有一种很具体的满足感。生活不是抽象的计划，而是这些被拎在手里的日常。 https://gv.cx/posts/rainy-afternoon/ Thu, 02 Jul 2026 15:30:00 +0000 https://gv.cx/posts/rainy-afternoon/ 下午下了一场雨。窗外的声音很均匀，像给房间加了一层背景。 原本想出门，后来决定留在家里。泡了一壶茶，读了几页书，又处理了一些拖了很久的小事。雨天让人更容易接受慢一点的节奏。 等雨停时，天色已经暗下来。路面反着光，空气里有一种被洗过的味道。 https://gv.cx/posts/small-restaurant/ Wed, 01 Jul 2026 19:05:00 +0000 https://gv.cx/posts/small-restaurant/ 晚饭去了楼下那家一直路过的小店。门面不大，菜单也简单，墙上贴着几张有点褪色的照片。 点了一份面和一盘小菜。味道不是惊艳的那种，但很舒服，像是可以在累的时候随便走进去的一顿饭。 有时候喜欢一座城市，就是从记住这些小店开始的。它们不显眼，却能让日子有落脚点。 https://gv.cx/posts/reading-notes/ Tue, 30 Jun 2026 21:15:00 +0000 https://gv.cx/posts/reading-notes/ 晚上读书的时候，看到一句关于耐心的话，停下来想了很久。 很多事情的变化都很慢，慢到每天看不出差别。可是一段时间以后回头看，又会发现自己已经离原来的位置很远。 记录也许就是这样。今天写下来的几句话，当下看起来很轻，过一阵子再看，可能会成为某段生活的坐标。 https://gv.cx/posts/phone-gallery/ Mon, 29 Jun 2026 16:45:00 +0000 https://gv.cx/posts/phone-gallery/ 下午清理手机相册，删掉了很多重复截图和模糊照片。 清理到一半时，忽然被一些小照片留住了：一顿饭、一段路、一张随手拍的天空。当时只是随手一拍，现在却能把那天的情绪带回来。 照片太多会变成负担，但留下来的那些，确实能帮人保存一些时间。 https://gv.cx/posts/slow-evening/ Sun, 28 Jun 2026 20:00:00 +0000 https://gv.cx/posts/slow-evening/ 今晚没有特别安排。吃完饭后洗了碗，开窗通风，然后坐在沙发上听了一会儿音乐。 这种晚上很容易被忽略，因为没有任何值得汇报的成果。但从身体的感受来说，它反而很重要。 人不可能一直处在推进状态里。慢下来不是浪费时间，有时候是在把自己重新接回来。 https://gv.cx/posts/city-bus/ Sat, 27 Jun 2026 13:25:00 +0000 https://gv.cx/posts/city-bus/ 今天没有打车，坐公交去了目的地。路线绕了一点，时间也更长，但刚好可以看看平时错过的街道。 车窗外的城市像一条缓慢展开的线。小区门口、学校围墙、修路的围挡、午后没什么人的便利店，都从眼前经过。 偶尔换一种速度，才会发现自己生活的地方并不只是几个固定坐标。 https://gv.cx/posts/simple-breakfast/ Fri, 26 Jun 2026 08:00:00 +0000 https://gv.cx/posts/simple-breakfast/ 早上做了很简单的早餐：鸡蛋、面包、一点水果，还有一杯热饮。 以前总觉得早餐随便应付一下就行，后来发现它会影响一整个上午。好好坐下来吃十分钟，整天的开头就不那么仓促。 生活里的秩序感，有时候不是来自很大的计划，而是来自这些重复的小动作。 https://gv.cx/about/ Mon, 01 Jan 0001 00:00:00 +0000 https://gv.cx/about/ 这是一个个人生活博客，用来保存日常记录和长期回看时仍然有价值的小片段。 后面可以把这里改成更具体的自我介绍、联系方式、常驻城市、兴趣清单，或者任何你想公开保留的内容。