它不追热点，也不追求日更，只希望每解决一个问题，就留下一条以后还能找到的路。

为什么是 Hexo + Butterfly

Hexo 的定位很纯粹：Markdown 写文章，一条命令生成静态页面，没有数据库，也没有需要长期维护的后台。对个人博客来说，这种简单本身就是一种可靠性。

Butterfly 则补齐了阅读体验：文章卡片、目录、搜索、归档、标签、暗色模式，基本开箱即用。它允许你只改配置就得到一个完整的站点，也留了足够的 CSS 和模板空间做自己的风格。

工具应该降低表达的摩擦，而不是成为表达本身。

这套站点怎么跑起来

站点完全静态化，文章和图片都放在本地，不依赖外部图床。核心命令只有几条：

# 安装依赖
npm install

# 本地预览（默认 4000 端口）
npm run server

# 生成静态文件到 public/
npm run build

# 重新构建并重启本机静态服务
npm run release

生成后的 public/ 可以直接交给 Nginx、GitHub Pages、Cloudflare Pages 或任意对象存储，不需要 Node.js 运行时。

已经打开的能力

• 本地全文搜索：不依赖第三方搜索服务，构建时生成索引。
• 亮 / 暗色模式：默认深海蓝暗色主题，也可以切回亮色。
• 文章目录与相关推荐：长文阅读时快速定位。
• 归档、分类、标签：按时间或主题重新组织内容。
• RSS 与 sitemap：/atom.xml 和 /sitemap.xml 开箱可用。
• 自定义 404：静态站点也可以有完整的错误页。

接下来写什么

后端开发、工程实践、工具效率，以及一些真实项目里的取舍和复盘。尽量写“为什么”，也尽量让步骤可复现。

如果这些内容刚好帮你少踩一个坑，那这个博客就有意义。

最后

先把第一篇文章发出来，比把博客装修到完美更重要。

剩下的，慢慢迭代。

这篇记录一次典型的接口性能排查过程。

现象：慢，但不知道慢在哪

一个商品详情接口，平均耗时 800ms，P99 超过 1.5s。调用方开始超时重试，数据库连接数随之上涨。

先别急着看业务代码。用 curl 打几次，把时间拆开：

curl -o /dev/null -s -w \
  'dns: %{time_namelookup}s\ntcp: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n' \
  'http://127.0.0.1:8080/api/products/42'

结果很稳定：网络和 TLS 都正常，时间几乎全部花在服务端处理上。问题被缩小到了应用内部。

第一步：让调用链说话

给接口加上分段计时，或者直接看 APM 的 span。这个案例里，一次请求里出现了 1 次主查询 + 3 次关联查询 + 1 次远程调用，其中三次关联查询是串行的。

伪代码大概是：

product = repo.get_product(product_id)
category = repo.get_category(product.category_id)       # 30ms
shop = repo.get_shop(product.shop_id)                   # 40ms
stock = client.get_stock(product.sku)                   # 120ms
reviews = repo.get_review_summary(product_id)           # 80ms

单看每一步都不算慢，但串起来、再乘以并发，就成了瓶颈。

第二步：把串行变并行

没有依赖关系的查询，没有必要排队。用线程池或异步任务把三次独立调用并发出去：

with ThreadPoolExecutor(max_workers=3) as pool:
    category_f = pool.submit(repo.get_category, product.category_id)
    shop_f = pool.submit(repo.get_shop, product.shop_id)
    stock_f = pool.submit(client.get_stock, product.sku)

    category, shop, stock = category_f.result(), shop_f.result(), stock_f.result()

耗时从相加变成取最大值，理论收益大约是 2/3。但要给线程池设置合理的队列和超时，避免把下游打垮。

第三步：检查 SQL 和索引

并发解决的是等待，数据库本身的慢查询还得单独处理。打开慢查询日志后，发现关联查询里有一张表走了全表扫描。

-- 优化前：status 区分度很低，优化器放弃索引
SELECT * FROM product_review WHERE product_id = ? AND status = 1;

-- 建立组合索引，并只取需要的列
CREATE INDEX idx_review_product_status ON product_review (product_id, status);

两个原则：

1. 组合索引的顺序：区分度高的列放前面，但也要结合查询模式。
2. 避免 SELECT *：减少回表、网络传输和序列化成本。

第四步：给热点数据加缓存

商品详情是典型读多写少。把商品基础信息、店铺信息和评论摘要放进 Redis，设置 5 分钟过期，并在更新时主动删除缓存。

cache_key = f"product:detail:{product_id}"
cached = redis.get(cache_key)
if cached:
    return json.loads(cached)

data = build_product_detail(product_id)
redis.setex(cache_key, 300, json.dumps(data))
return data

缓存的关键不是“加上”，而是想清楚：什么时候失效、缓存穿透怎么办、数据不一致能接受多久。

结果

复盘

这次排查没有用到什么高深技巧，关键步骤是：

1. 先把“慢”拆成可度量的时间段；
2. 用调用链找到真正的等待点；
3. 能并行的并行，能缓存的缓存，该建索引的建索引；
4. 用数据验证，而不是凭感觉。

性能优化不是把代码写得更复杂，而是让每一次等待都有明确的理由。

把项目依赖的服务写进 docker-compose.yml，再配一个 Makefile，新环境从 clone 到跑起来可以缩短到几分钟。

目标：一条命令启动

一个典型的后端项目，本地至少需要：

• MySQL：持久化数据
• Redis：缓存和会话
• 可选：RabbitMQ、MinIO、邮件沙箱

与其在文档里写十几步安装教程，不如把这些服务声明成代码。

目录结构

project/
├── docker-compose.yml
├── .env.example
├── Makefile
└── app/

docker-compose.yml 放在项目根目录，环境变量放在 .env，模板提交到仓库，真实值不提交。

Compose 文件

services:
  mysql:
    image: mysql:8.4
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD:-root}
      MYSQL_DATABASE: ${MYSQL_DATABASE:-app}
    ports:
      - "3306:3306"
    volumes:
      - mysql_data:/var/lib/mysql
      - ./ops/mysql/init:/docker-entrypoint-initdb.d:ro
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-proot"]
      interval: 5s
      timeout: 3s
      retries: 20

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: ["redis-server", "--appendonly", "yes"]
    ports:
      - "6379:6379"
    volumes:
      - redis_data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 20

volumes:
  mysql_data:
  redis_data:

几个容易忽略的点：

• healthcheck 很重要：应用启动脚本应该等依赖健康，而不是简单 sleep 10。
• 数据卷命名：不要随便 down -v，否则本地数据会一起消失。
• 端口冲突：用 ${MYSQL_PORT:-3306}:3306 把宿主机端口做成可配置项。
• 初始化脚本只执行一次：MySQL 的 initdb 目录只在数据卷为空时运行。

用 Makefile 收敛命令

把常用操作固定下来，团队里就不需要每个人记一套命令：

.PHONY: up down logs psql redis reset

up:
docker compose up -d --wait

down:
docker compose down

logs:
docker compose logs -f --tail=100

psql:
docker compose exec mysql mysql -uroot -proot app

redis:
docker compose exec redis redis-cli

reset:
docker compose down -v
docker compose up -d --wait

--wait 会等待 healthcheck 通过，比 sleep 可靠得多。

应用容器化：开发阶段先别急

本地开发时，我通常只把基础设施放进 Docker，应用仍然在宿主机上跑。这样可以保留断点调试、热更新和 IDE 的完整体验。

等需要验证“干净环境”时，再用一个 Dockerfile 构建应用镜像：

FROM eclipse-temurin:21-jre
WORKDIR /app
COPY target/app.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

如果确实要把应用也放进 Compose，可以加一个 app 服务，并用 depends_on 加上健康检查条件：

depends_on:
  mysql:
    condition: service_healthy
  redis:
    condition: service_healthy

不要提交的东西

.env
*.log
data/

同时提供 .env.example，把变量名和默认值写清楚。新同事复制一份就能启动。

最后

Docker Compose 的价值不是“用了容器”，而是把环境变成可读、可复现、可版本控制的代码。

当环境不再是口头约定，排查问题才能从“你那边是什么版本”回到真正的代码和数据。

好的开发环境应该像一个好的函数：输入明确，输出可复现。

于是我把 RSS 重新放回了信息食谱。

RSS 没有死

很多人以为 RSS 是被算法淘汰的。其实它只是从大众视野里退场，变成了一个更安静的工具：你决定订阅谁，就只看见谁。

没有“猜你喜欢”，没有无限下拉，也没有为了停留时长而设计的标题。打开阅读器，列表有尽头，读完就可以关掉。

我的订阅原则

1. 少而精：订阅源控制在 30 个以内，超过就删。
2. 按主题分组：技术、阅读、设计、朋友。不同状态打开不同分组。
3. 不追求清零：未读数不是任务，过期未读就批量标记已读。
4. 保留原文链接：阅读器只是入口，重要的文章回到原站读。

一个小工作流

看到值得收藏的文章，不再只是点个赞，而是：

• 用稍后读工具存下；
• 周末统一读；
• 值得留下的，整理成笔记；
• 特别好的，写进博客。

这个流程有点慢，但慢下来之后，信息才真正变成了自己的东西。

推荐几个订阅

• 阮一峰的网络日志：每周五的科技动态，信息密度很高。
• 少数派：效率工具与数字生活，适合按需翻阅。
• The Marginalian：关于书、艺术与生活的长文，适合周末。
• Hacker News：技术社区的高信号讨论，建议只看前两页。

最后

RSS 不会替你筛选出“最重要”的信息，但它把选择权还给了你。

在一个越来越吵的互联网里，能自己决定听什么，已经是一种奢侈。

这份清单不追求全，只记录真正在我的日常里反复出现的东西。

基础三件套

# 找文件，比 find 更好记
fd "config" ~/projects

# 找内容，默认尊重 .gitignore
rg "TODO" src/

# 看目录，带图标和 git 状态
eza -la --git

fd、rg、eza 分别替代了 find、grep、ls。它们不是必需品，但用过之后很难回去。

让 shell 更顺手

历史记录搜索

把上下键绑定到前缀搜索，输入几个字母就能找到之前的命令：

# ~/.inputrc
"\e[A": history-search-backward
"\e[B": history-search-forward

别名不是偷懒

alias gs="git status -sb"
alias gd="git diff --stat"
alias ll="eza -la --git"
alias ..="cd .."

别名省下的不是几秒钟，而是每次切换上下文时的注意力。

Git 的几个小习惯

• 提交前先 git diff --staged，确认没有误加文件。
• 用 git switch -c 代替 git checkout -b，语义更清楚。
• 提交信息写“为什么”，而不只是“做了什么”。
• 定期 git fetch --prune，清理已经消失的远程分支。

一个够用的编辑器配置

无论用 Vim 还是 Neovim，先把这几件事做好：

1. 相对行号；
2. 快速模糊查找文件；
3. 保存时自动格式化；
4. 一套看得舒服的配色。

插件不必多。配置是为了减少摩擦，不是为了增加仪式感。

最后

工具的意义，是让人忘记工具的存在。真正重要的，始终是用它写出的代码、解决的问题，以及省下来的那点时间用来做什么。

如果这份清单里只能留下一个建议，那会是：把每天重复三次以上的动作，变成一条命令。