今晚处理社区生鲜电商平台的线上突发问题，加了个急班。
线上反馈的核心痛点很直接：普通用户在浏览商家产品时，无法顺畅查看历史留言与互动，导致消费者与基地商家之间的沟通链路受阻。经过排查与调整，我们理顺了用户中心的前台留言与双向回复逻辑，顺利把核心通道修复完毕。
但在排错和发布的过程中，业务同事顺带提了一个看似很合理的改进建议：
“既然都在处理这一块，能不能顺便在‘已完成订单’列表里，标明哪些商品已评价、哪些还没评价？做个未评价提示，这样体验更完善。”
坦白说，这个建议从体验上看确实合情合理。如果是在日常的正常迭代里，完全可以作为体验优化排入需求池。
但在今晚紧急发布的节点上，我还是果断决定：先不加。
为什么在热修时必须做减法？
在软件开发中，最危险的陷阱之一往往就是：“来都来了，顺手改了吧。”
每当生产环境发生故障需要紧急发布时，团队往往处于高压状态，测试与验证的时间被压缩得极短。这时候只要有人提了一个看似顺理成章的微小需求，工程上极容易产生误判：
- 低估表面简单的底层代价：在订单列表里精准展示每个商品的评价状态，表面上只是前端加个标签，底层却可能涉及订单主子表与评价表的多表联查或状态同步。在毫无压测的前提下匆忙改动核心订单接口，极易引发生产数据库的慢查询甚至锁表；
- 分散核心目标的专注度：今晚的目标只有一个——尽快恢复受阻的关键沟通链路。如果分心去赶写新特性的边界判断，留给核心修复的回归测试时间就会被严重挤占；
- 引入不可预测的新风险：缺乏充分回归测试的代码一旦上线，极可能引发次生灾难，把一次原本小范围的热修复拖入通宵抢救的恶性循环。
保护生产环境永远是第一准则
对于这个新建议，我给出的评估结论很坚定：需求很有价值，但紧急度不高；由于改动牵涉较深，无法确保仓促上线后的系统稳定性，因此绝不顺风车上线。
在代码里做加法很容易，敲下键盘就能实现；但在压力和期待面前敢于做减法、踩刹车，才是一个工程师应有的专业与克制。
生产环境不相信侥幸。每一次应急发布，都应该像外科手术一样保持极限的精准、小巧与迅速：只修复病灶，绝不节外生枝。确保系统稳定活着永远是第一位，至于锦上添花的优化，完全可以留到明天的阳光下从容地打磨。