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

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

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

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

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

Markdown 真正进入团队使用后，通常不会只经过一种渲染方式。编辑器里要实时预览，命令行里要批量导出，线上站点还要再做一次正式渲染。只要这三条链路的规则不一致，内容就会慢慢长出很多“本地看着没问题，上线以后才发现不对”的小坑。

静态站点的搜索一开始看起来很简单：把页面内容抓出来，做个索引，前端输入关键字再匹配就行。真做起来以后，经常会发现搜索结果里全是“上一篇、下一篇、文章目录、相关文章”这些导航文字，真正想找的正文反而被稀释了。

很多人第一次做 Markdown 目录自动生成，注意力都会放在“怎么把标题列出来”上。真到了文档越来越多、开始需要分享链接和长期维护的时候，问题往往不是目录能不能生成，而是同一篇文章在编辑器预览、导出的 HTML、线上静态页里，标题锚点是不是完全一致。

问一个很现实的问题：为什么很多 Express 项目都有认证中间件、日志中间件、跨域中间件，却偏偏把错误处理中间件留到最后才补？
我的答案是，因为它不像“功能”那样立刻可见，只有出问题时你才会想起它。

云服务器磁盘扩容这件事，很多时候会被理解成“容量加上了就结束”。
但 2016 年我自己处理这类操作时，越来越不敢只看控制台上的容量变化。因为真正决定这次扩容有没有落地到系统可用状态的，往往不是云平台页面，而是机器里挂载点和开机自动挂载有没有确认好。