前后端联调最怕的不是接口还没写完，而是大家以为已经说清楚了：字段名临时改了、枚举多了一个值、错误结构不一致、分页参数含义不同。API 契约测试的价值，就是把这些口头约定变成可执行的检查，让接口变更在进入主干和发布前就暴露出来。
用 Docker Compose 打造可维护的本地开发环境
本地环境最怕两件事：新同事跑不起来，老项目没人敢动。Docker Compose 的价值不只是“一条命令启动数据库”，而是把应用、依赖、端口、数据卷和调试入口写成可以审查的工程契约。下面这份清单适合中小型 Web 项目，也适合把散落的 README 步骤收敛成稳定入口。
把日志写到能排障：结构化日志、Trace ID 与脱敏清单
很多系统不是没有日志，而是日志只能证明“代码曾经跑过”。真正能排障的日志，应该在事故发生时回答三个问题：这是谁的请求、走到了哪一步、为什么变慢或失败。把日志从散乱句子升级为结构化事件，再配合 Trace ID、字段规范和脱敏策略，排查效率会比临时翻字符串高很多。
把 HTTP 接口做稳：超时、重试与幂等的工程清单
很多接口事故并不是因为业务逻辑复杂，而是因为一次慢查询、一次网络抖动、一次客户端重复点击，把原本正常的链路拖进了未知状态。HTTP 调用要做稳，不能只靠“失败再试一次”。更可靠的做法，是把超时、重试和幂等放在一起设计：超时负责止损，重试负责修复短暂失败，幂等负责保证重复请求不会产生重复副作用。
用 Makefile 统一项目任务入口：从本地脚本到 CI 复用
项目越做越久，常见命令就越容易散落：README 里一段、package.json 里几段、CI 配置里再复制几段。新人要先问“怎么跑测试”，老成员也会在不同终端历史里找命令。Makefile 的价值不只是编译 C 项目，它还能给任何仓库提供一个稳定、可读、可组合的任务入口。
用 SQLite 做轻量本地数据层：WAL、事务、索引与迁移清单
很多内部工具、桌面应用、边缘服务和个人项目，并不需要一上来就接 PostgreSQL 或 MySQL。SQLite 的优势不是“玩具级简单”，而是把数据库能力放进一个普通文件里：部署少、依赖少、备份直观。只要把连接初始化、事务、索引和迁移这几件事做扎实，它完全可以承担一个可靠的本地数据层。
让终端更顺手的几个命令行工具
在终端里待久了会发现：真正拉开效率差距的，往往不是什么高深技巧，而是有没有用上几款更现代的小工具。它们大多是对 grep、find、cat、cd 这些老命令的「平替升级」，装上之后基本回不去了。下面这几个是我天天在用的。
Git「后悔药」救命指南：改错了、删没了、提交歪了怎么办
用 Git 最慌的时刻，往往不是写代码，而是「我刚才那一下是不是把东西搞没了」。好消息是：只要你曾经 git add 或 git commit 过，几乎没有真正找不回来的东西。 这篇按「我闯了什么祸」来组织，遇到对应场景直接抄命令。
用 GitHub Actions 自动部署 Hexo 博客（含 /blogs 子路径踩坑）
搭一个 Hexo 博客不难，难的是「每次写完还要本地 hexo generate 再手动推一堆静态文件」。把构建交给 GitHub Actions 后，工作流就变成：写文章 → git push → 几十秒后自动上线，本地连 node_modules 都不用装。这篇记录一套能直接抄的配置，以及我自己踩到的几个坑。
网页托管平台怎么选？GitHub Pages / Vercel / Netlify / Cloudflare 对比，以及最省事的图床小镇 HTML 托管
想把网页放到网上，第一步往往就卡在「用哪个托管平台」。其实在选之前，先分清楚自己属于哪一类需求，答案就清楚了一大半：
- 要上线一个完整的网站 / 博客（多页面、要持续更新、最好有自己的域名）——选 GitHub Pages、Vercel、Netlify、Cloudflare Pages 这类整站托管平台。
- 只是想快速把一个 HTML 页面发出去（AI 生成的活动页、简历页、作品集、客户演示稿……）——这时候最省事的是图床小镇的 HTML 托管：上传一个文件就出链接，零配置。
下面分别说。