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

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

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

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

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

看到 mysql.proc 相关错误时，很多人第一反应是“表坏了”。
这个判断不完全错，但 2016 年我在看这类问题时越来越觉得，真正值得警惕的不是某一张系统表本身，而是它背后通常暴露出一整段升级和权限处理流程都没收好。

数据库升级这种事，很多团队会认真写升级步骤，却不认真写回滚步骤。可真正到了线上，最能决定你心态的往往不是“怎么升”，而是“如果升坏了，能不能稳稳退回来”。

图形化数据库工具很容易让人操作得太顺。
尤其是像 DataGrip 这类客户端，连接、查询、查看结构都很方便，很多动作看上去像在本地演练一样自然。但 2016 年我开始更频繁地用这类工具处理线上数据后，最先养成的习惯反而不是记快捷键，而是先看自动提交有没有关掉。

2016 年接手 Java 项目时，我遇到过一种很典型的混乱：同样是处理用户逻辑的类，有的叫 UserDao，有的叫 UserMapper，有的叫 UserServiceImpl，还有的直接叫 UserManager。项目还能跑，但只要需求稍微一变，大家就会先花时间猜“这个类到底管什么”。

图片上传这类接口最容易在需求讨论里被说成一句话：选文件，传上去，返回地址。
可 2016 年我在做这类功能时越来越明显地感觉到，一个上传接口如果一开始只关注“体验顺不顺”，却没有先限制大小、类型和错误边界，后面出问题会非常频繁。