2020 年前后，微服务这个词在很多团队里都很热。系统一旦变大，大家很自然就会想：是不是该拆服务了？这个方向当然有它的价值，但我后来越来越警惕一种冲动，就是把“拆”本身看成答案，却没有先补上对应的观测和降级能力。

Docker 本地环境用久了以后，几乎都会经历一个阶段：旧容器没删干净，历史镜像堆了不少，没在用的 volume 和网络也越来越多。这个时候很多人为了图快，直接一通删除，结果把本来还想保留的数据库数据也一起带走了。环境清理这件事看似只是几条命令，其实很考验顺序感。

有些容器问题并不是“起不来”，而是明明已经在运行，表现却和预期不一样。比如环境变量没生效、工作目录不对、配置文件路径错了、依赖包实际没有安装完整。这个时候如果只会不停重启容器，排查会非常低效。对这类问题来说，docker exec 往往比“再试一次”更有价值，因为它让你直接进入现场。

Docker 用到一定阶段后，几乎都会碰到一个问题：容器里的数据到底是保存在 volume，还是直接绑定宿主机目录。这个选择看起来像是命令层面的细节，实际上很影响本地开发效率。因为它决定了你改代码是否能实时生效、数据库数据是否好迁移、环境重建时会不会把重要内容一起清掉。

本地容器一旦启动失败或者接口突然异常，很多人的第一反应都是先 docker exec 进去看看，或者直接把容器删掉重启。这样做当然有时候也能解决问题，但从排查效率看，并不总是最优。很多容器问题，其实靠 docker logs 就能先把大方向判断出来，尤其是把 follow、tail、since 这些选项用顺手以后，定位速度会快不少。

很多人第一次写 Dockerfile 时，只关心“能不能构建成功”。等到项目稍微变大一点，就会开始抱怨镜像构建太慢。这个时候常见的反应是去找加速源、换基础镜像、甚至怀疑 Docker 本身不稳定。但经验告诉我，真正拖慢本地构建速度的，很多时候不是网络，而是你自己把缓存层次和构建上下文写得太随意了。

刚开始用 Docker Compose 做本地联调时，最容易犯的错误就是还在用宿主机思维理解容器之间的访问关系。比如 API 容器去连数据库时，配置里还写 127.0.0.1，结果明明数据库已经启动了，应用还是一直报连接失败。这个问题其实不是 Compose 配错了，而是没有建立起一个很关键的认知：同一个 Compose 网络里，服务名本身就是彼此访问时最方便的地址。

很多人刚在 Mac 上装好 Docker Desktop，第一反应都是先拉镜像、起容器、跑服务。等到容器越来越多，才开始发现编译慢、数据库启动慢、桌面风扇狂转、系统内存被吃掉一大块。这个时候再怀疑镜像源、怀疑命令写法，往往已经偏题了。对 Mac 环境来说，资源限制配置本身就是本地开发体验的一部分。

用 slice 实现栈和队列几乎是 Go 入门练习里的必做题。因为语法不复杂，append 也足够顺手，所以很多人会觉得这类题没什么难度。但真正把它写进稍微像样一点的小程序里时，你会发现问题并不在“会不会写”，而在“有没有考虑清楚容量变化、出队后残留引用、空结构操作这些细节”。

很多人刷算法题时喜欢挑复杂题，觉得这样更有挑战。但从练代码基本功的角度看，真正值得反复写的，往往是那些规则简单、边界丰富的小题。递归和二分查找就是这种题型的代表。它们不靠花哨技巧取胜，却非常适合训练你是不是能把停止条件、输入约束和函数职责写清楚。