码上札记

霜降：气肃而凝，露结为霜

Fri, 23 Oct 2026 08:00:00 +0800

今天霜降。二十四节气里的第十八个，也是秋天的最后一个节气。过了今天，冬天就算是真正在路上了。

古人说"气肃而凝，露结为霜"。清晨出门，草叶上一层薄薄的白，阳光一照亮晶晶的，空气里都是清冽的味道。这是一年里秋天最有仪式感的一个早晨。

霜降有三候：一候豺乃祭兽，二候草木黄落，三候蛰虫咸俯。叶子黄了落了，虫子也躲进洞里准备冬眠。天地都在做减法，人也该跟着收一收。

民间有个说法：霜降吃柿子，冬天不感冒。老祖宗的讲究未必全有科学道理，但霜降前后的柿子确实最甜——经过霜打的柿子，红得透亮，咬一口满嘴蜜。

一年走到这个节点，好像也该回头看看：春天发的芽、夏天流的汗，到秋天总算结了果。剩下的日子，添衣、早睡、吃点热乎的，把自己照顾好，等下一个春天。

天凉了，记得加件外套。

写代码三年，我踩过的那些坑

Thu, 22 Oct 2026 21:30:00 +0800

那些年踩过的坑

写代码这几年，被各种问题按在地上摩擦过无数次。挑几个印象最深的写下来，也算给自己提个醒。

第一个坑：本地好好的，上线就报错。多半是路径斜杠、环境变量、时区不一致这类环境差异。后来养成习惯——上线前先在测试环境完整跑一遍。

第二个坑：日志打的是天书。报错信息只写一句"系统错误"，出了问题根本查不到是哪行。现在凡是 catch，我都把请求参数和堆栈完整记下来。

第三个坑：过早优化。刚开始总想着写得"优雅"，结果绕了一大圈还不如直接 for 循环好读。先让代码跑对、再让它跑得快，最后才谈优雅。

坑踩多了就会发现，大部分 bug 不是技术问题，是习惯问题。慢慢来，比较快。

Code Review 到底在看什么？

Thu, 22 Oct 2026 18:20:00 +0800

Code Review 到底在看什么？

代码审查不是挑刺，而是保证质量、共享知识的重要环节。

看这几点：逻辑对不对、边界情况考虑没、命名清不清楚、有没有明显的性能问题、测试覆盖了没。

提意见时对事不对人，写代码的人也别把审查当否定。一来一回，整个团队的水平都在涨。

远程办公几年，我的几点体会

Thu, 22 Oct 2026 08:45:00 +0800

远程办公的几点体会

在家办公这几年，效率和体验都有，坑也不少。

好处是省下了通勤，时间整块，可以专注做事。坑在于边界容易模糊——工作和生活混在一起，反而更累。

我的经验：固定一个专门的工位，到点上班到点下班，主动和同事多沟通，别让人感觉你"消失了"。

Git 常用命令速查：从入门到提交不慌

Wed, 21 Oct 2026 22:15:00 +0800

最常用的十条命令

Git 命令有几百条，但日常开发 90% 的时间只用下面这些。背熟它们，提交代码就不会慌。

git status               # 看当前改了啥
git add .                # 全部加入暂存
git commit -m "说明"      # 提交
git pull                 # 拉取远端最新
git push                 # 推到远端
git log --oneline        # 看提交历史
git checkout -b feat/xx  # 新建并切到分支
git merge feat/xx        # 合并分支
git reset --hard HEAD~1  # 回退最近一次提交

三个保命习惯

第一，提交前一定 git pull，别在本地改半天结果冲突一堆；第二，大改动拆成小提交，别一次改几十个文件；第三，重要分支别随便 reset --hard，先用 git stash 保命。

为什么我开始坚持写技术博客

Wed, 21 Oct 2026 09:30:00 +0800

为什么我开始写技术博客

写博客最初是为了记录，后来发现它带来的好处远超想象。

第一，写一遍胜过读三遍——能讲清楚才是真懂；第二，过几个月回头看，自己解决过的问题一目了然；第三，偶尔被同行看到、交流两句，能认识不少人。

不用写得多好，先开始写，比纠结排版和选题重要得多。

MySQL 索引为什么快？一次讲透 B+ 树

Tue, 20 Oct 2026 20:00:00 +0800

索引为什么能快这么多？

没有索引时，查一条数据要从头到尾扫全表，数据量大了就是灾难。加了合适的索引，MySQL 用 B+ 树把查找复杂度从 O(n) 降到 O(log n)。

B+ 树是什么结构？

想象一棵多层的多叉树：根节点和内部节点只存索引，真正的数据都存在最底层的叶子节点里，而且叶子之间用双向链表串起来。这样范围查询特别快：找到起点，沿着链表往后扫就行。

几个实战要点

第一，最左前缀原则：联合索引 (a,b,c)，查 a、a,b、a,b,c 才走索引；第二，不要在索引列上做函数运算，否则索引失效；第三，小表、区分度低的字段别建索引，写多读少的表也要谨慎。

新人最容易犯的 10 个编码错误

Mon, 19 Oct 2026 20:35:00 +0800

新手最容易犯的编码错误

刚入行那会儿，这些坑我一个没少踩。列出来给后来者提个醒。

第一，变量名随便起，过两周自己都看不懂；第二，不写注释，逻辑全靠脑补；第三，异常直接吞掉，catch (e) {} 什么都不做；第四，密码写死在代码里。

这些问题不难，但不改的话迟早翻车。代码是写给人看的，顺便能让机器跑就行。

治愈系日剧推荐：生活没那么糟

Sun, 18 Oct 2026 22:20:00 +0800

最近重温了一部很治愈的日剧，讲的是几个年轻人在小餐馆里的日常。没有大起大落，就是吃饭、散步、发呆，但看得人心里暖暖的。

好的治愈系作品不是让你哭，而是让你觉得：好好吃饭、好好睡觉、认真过每一天，本身就很了不起。

累的时候就看一部吧，生活没那么糟。

RESTful API 设计入门：前后端分离时代的接口约定

Sun, 18 Oct 2026 21:00:00 +0800

什么是 RESTful？

REST 不是标准，而是一套架构风格：用 URL 表示资源，用 HTTP 方法表示操作，用状态码表示结果。前后端分离之后，接口设计的好坏直接决定了协作效率。

四条核心约定

第一，URL 用名词复数，比如 /api/users，不要写成 /api/getUser；第二，用 HTTP 方法表达动作：GET 查询、POST 新增、PUT 更新、DELETE 删除；第三，返回统一 JSON 结构：

{
  "code": 0,
  "msg": "ok",
  "data": { "id": 1, "name": "tom" }
}

第四，错误用合适的状态码：参数错 400、没权限 403、找不到 404、服务器错 500。

一个常见误区

不要把所有操作都塞进 POST。一个接口如果读的是数据，就老老实实 GET，缓存、日志、监控都会轻松很多。