今天遇到一个典型的“甩锅现场”，想和大家聊聊：当线上出问题时，为什么有些人的第一反应是“谁的责任”，而不是“怎么解决”？
事情经过
我们做的是餐厅收银系统。之前的版本是：用户点 2 份 A 商品下单后，过会再追加 3 份，结算时账单是两条明细，总数是 5。
新版本需求要求前端展示时将同类食物合并，显示为一条数据，数量累加。
结果测试反馈给安卓端：点了 2 份 A 再加 3 份，合并后数量竟然变成了 6 份。
安卓同事的第一反应： “这绝对是后端给的数据有问题！我只是拿到数据直接合并展示，跟我有啥关系？”
测试随后找到了我。我没急着反驳，直接说：“行，你先复现给我看，我排查一下原因。”但因为我手头的安装包还是老版本，逻辑不同，没能当场复现出“6 份”的问题。
安卓同事听到后瞬间急了，大声嚷嚷：“你包是旧的当然看不出来，我给你发个新包，你赶紧自己测测！”
我当时就气笑了，直接怼回去： “新包旧包影响的是前端展示逻辑，跟后端给的数据结构有啥关系？如果是接口数据错了，新旧包表现出来的错误数据应该是一致的；怎么，后端数据还会看你的包版本来下菜碟？”
安卓同事顿时语塞，灰溜溜地走了。
😡 这已经不是第一次了
这种“防御性编程”不仅体现在排查 Bug 上，更体现在日常协作中。
只要涉及到他和关系好的同事需要改动代码，他们就会想方设法把需求推给后端。比如，当数据需要清洗并对接给 Python 另一个系统时，他会据理力争地强调前端改动量有多大、逻辑有多复杂，最后结论永远是： “这事儿后端顺手处理一下不就行了？”
这种“推诿文化”最让人心累的地方在于：沟通成本远大于开发成本。
💡 一点反思：技术人的底气不是靠“甩锅”撑起来的
在职场中，遇到 Bug 其实并不可怕，可怕的是**“拒绝排查、急于撇清”**的态度。
- 先解决问题，再复盘责任： 线上出 Bug 就像救火，先灭火是第一位的。火还没灭就开始争论谁没关煤气，除了让损失扩大，没有任何意义。
- 专业度决定话语权： 像这种“版本不同导致数据逻辑不对”的低级借口，不仅甩不掉锅，反而暴露了自己对业务逻辑的无知。
- 协作不是零和博弈： 今天的改动虽然让你多写了几行代码，但建立起来的团队信任度是无价的。总是想方设法把工作推给别人，路只会越走越窄。
