VSCode 用久了之后，配置文件很容易变成一个巨大的杂物箱。今天装一个插件改一条设置，明天为了某个语言服务再补两条，过几个月回头看，自己都说不清哪些是个人习惯，哪些是项目要求，哪些只是某次临时实验留下来的痕迹。

Java 集合一学到 ArrayList 和 LinkedList，很多人就会形成一个很顺手的印象：前者适合查，后者适合增删，于是当某段代码出现“可能会插入删除”的需求时，就很自然地想把 LinkedList 搬出来。可真到业务代码里，这个选择远没有口诀那么简单。

学 Java 时，很多人第一次接触不可变对象，都会很快记住 final 这个关键字。于是项目里就容易出现一种误会：只要字段加了 final，对象似乎就安全、稳定、不会被改坏了。可真正写一阵业务之后你会发现，事情没这么简单。

刚开始学 Go，并发部分最容易让人紧张的词就是“死锁”。这当然没错，因为死锁一出现，程序常常会非常明显地挂在那里。可等你真正把 Go 服务跑起来一段时间后，会发现另一类问题更难受：goroutine 没有马上死掉，而是在后台一点点堆起来。

Java 集合遍历删除这个问题，很多人都知道有坑。
可真正麻烦的地方在于，它不是每次都立刻用最醒目的方式出错。有些代码在某个数据量、某种路径下能跑，看起来像是可用的，结果一换场景就开始报错或者漏删，这种“看起来能跑”的状态反而最危险。

很多人学 Java 时，最先熟悉的就是 String、ArrayList、HashMap 这些基础类。也正因为太熟了，项目里反而经常是在它们身上出问题。不是因为类本身复杂，而是因为大家太容易“顺手就用”，很少停下来想当前场景到底合不合适。

第一次写 Dockerfile 时，很容易把它理解成“按步骤把环境搭起来”就好。
可 2017 年我在反复构建 Node 项目镜像时，越来越明显地感觉到：Dockerfile 里的 COPY 顺序不只是可读性问题，它会直接决定构建缓存是不是容易失效。

现在大家一提 Docker 镜像优化，很容易先想到多阶段构建。但 2017 年那会儿，很多团队日常还没有把这套玩法完全用顺。想让镜像体积别太夸张，往往还是靠一些更基础、也更朴素的习惯。

用 glob 做批处理时，大家通常会先想“我该怎么把目标文件匹配出来”。
可 2017 年我自己写这类脚本越来越多之后，反而最警惕另外一件事：是不是把不该处理的生成目录也一起扫进来了。

第一次在 Node.js 脚本里用 glob，会有一种很爽的感觉：以前得自己递归目录、判断后缀，现在一条模式就能把文件找出来。可真把它用进构建脚本、批处理脚本、资源扫描脚本以后，就会发现路径这件事比模式本身更容易出问题。