Java 项目里很容易出现一种“看上去很稳”的异常处理：每一层都在 catch，每一层都在包一层自己的提示，最后用户确实看不到原始异常了，但开发排查时也很难再看到真正的现场。
2017 年我在处理一些线上问题时，对这一点的体会越来越深。

“接口和抽象类怎么选”几乎是每个 Java 学习阶段都会碰到的问题。
很多回答会从语法、继承、默认实现这些点切入，这些都没错。但 2017 年我在项目里慢慢形成的判断是：真正决定选择的，常常不是当前写起来哪个方便，而是未来变化会往哪个方向长。

Java 8 刚出来那阵，很多人讨论接口默认方法，讨论点常常是“它是不是打破了接口的纯粹性”。我后来在项目里真正用过几次后，反而觉得更实际的问题是：哪些重复代码适合放进去，哪些不适合。

很多人学日志排查，最先接触的是 tail -f。这当然很好，因为它直观、反馈快。
但 2017 年我自己排查线上日志越来越多之后，一个很明显的体会是：只会单独用某一个命令，和真正排日志顺手，中间差着一层“能不能把工具组合起来”。

早些年排查线上日志，很多人的第一反应都是 tail -f。我也一样，因为它直接、顺手，而且大多数教程都是这么教的。可 2017 年之后，随着 systemd 越来越常见，我慢慢发现，如果 Node 服务本身就是被 systemd 接管的，只盯着 tail 其实会漏掉很多关键信息。

Docker 刚上手时，最容易让人兴奋的是“起一个容器真快”。
可一旦把数据库也放进容器里，很多人第一次真正理解数据卷，往往不是看文档时，而是某次容器删掉、重建或者路径挂错之后，才突然意识到数据和镜像根本不是一回事。

Docker Compose 刚开始用的时候特别有吸引力，因为你很快就能把 Node.js 服务、Nginx 代理、数据库一起拉起来。可 2017 年我自己真正把它放进开发流程后，最大的感受不是“真方便”，而是“边界太容易乱了”。

Nginx 反向代理 Node 服务时，很多问题表面上都像“接口有 bug”。
可 2017 年我自己在处理代理和部署问题时，越来越多时候发现，根因其实不在业务代码，而在请求经过 Nginx 之后，有些关键信息没有被完整传下去。

Markdown 目录自动生成刚用起来时，体验通常都很好。
大纲一键出来，长文章可读性立刻上去，写作者自己也更容易把结构收住。但 2017 年我在持续写技术文档和博客时，慢慢发现目录真正麻烦的地方，不在生成那一刻，而在后面你继续润色标题的时候。

以前我也干过那种事：线上着急同步代码，一句强制拉取就把本地改动全盖掉。问题是这种做法虽然快，但太依赖运气。只要本地还有没整理完的文件、临时调试记录或者还没想好是否提交的修改，一次粗暴覆盖就可能把自己坑到。