不怕神一样的对手，就怕猪一样的队友。
善变型
做一个项目。接口什么的之前都没有。大体逻辑是A调用我的接口，我调用B的接口。
接口在设计时各方定义好了，我和B都开发完了。A说接口这样定义不好，要改，那意味着我改，我还要告诉B改。既然人家提出来了，要爱伙伴，尊重人家的想法，那就改吧。
刚改完，A提出又要改一版。这我怎么好意思再跟B说？
我就开始质疑A了:"为什么又要改呀？"
A说:"我是上游，让你改你就改就行了。"
这是平时关系太熟，杀熟的节奏？我当时又无可奈何。心里啪啪扇着对方的巴掌，嘴里还扮着俏皮说:"我哭，我哭，我哇哇哭，哭一会儿再改。"
在办公室，如果有人对你半开玩笑说:"不太厚道啊，哈哈哈哈。"心里多半在说:"你个人渣！社会败类！&$#……"
最后我这边做了适配，上游再怎么改，给下游只增加参数。我这边代码会丑一点，所以我写了注释: "这段不必要的适配是由于上游接口定义总变，并没有其他逻辑上的原因。"
这样处理的逻辑是新业务上线，本身没有多少量，性能什么的否不是瓶颈。反而哥其他团队维持好关系，维护好口碑对整个项目和后续事宜更有益。
嘴硬型
一些开发大概遇到过和我一样的烦恼:企业版的某信问题太多。以至于和他们交互，经常会脱口而出:"又遇到了XX的bug!"
有时候是他们的问题有时候不是，但是会特别像是。
举个不是的。有次接XX回调丢了消息。由于量很少，就是晚上9点左右丢了几笔，后来就没有了。就把这件事优先级放的很低，当时没有处理。1个月之后又是同样的问题，也是晚上9点左右，有少量几笔。
那个公司我有朋友，我是知道他们晚上9点是他们升级的窗口。查了他们官网，果然查到了那天有升级。我们没有变更，他们升级了就出问题。是不是很像他们有问题？
但仔细想想又不对，如果每次升级就出问题，不像是业务问题，更像是技术问题。他们那样的大公司不该出现这样的技术问题，这种技术问题更像是我们这种创业小公司会出现的。
果然，经过仔细排查之后发现:我们作为应用程序，上层用的是nginx代理。有个参数起到了至关重要的作用：proxy_ignore_client_abort
proxy_ignore_client_abort 是 Nginx 的一个指令，用于控制 Nginx 在客户端连接意外关闭时的行为。默认情况下，当客户端在请求过程中突然断开连接，Nginx 会立即终止与后端服务器的连接。这样做是为了避免后端服务器的资源浪费，尤其是在处理一些需要长时间处理的请求时。
通过设置 proxy_ignore_client_abort on;，Nginx 将忽略客户端的断开行为，继续将请求发送到后端服务器，直到后端服务器处理完成。这样，即使客户端断开连接，后端服务器也能继续完成请求处理。
之前我们使用默认配置，这会造成客户端也就是我们对接的平台意外关闭时，回调请求没有发到我们应用端。对于这种回调类型的请求，更合理的设置方式是设置 proxy_ignore_client_abort on;
而默认方式更适合那种客户端请求要拿到处理结果，如果客户端不拿到处理结果没有意义的，比如：支付、下单、自己作为客户端请求下游，但是并不是适合这种回调请求。
这个技术问题不是今天讨论的重点。今天要讨论的是他们真正出问题的场景: 在拉群时拉了群主和一个管理员，放一天后管理员修改自己的群昵称。然后管理员身份就丢失了。手动设置回来，再改昵称又丢失管理员身份。每次必现。
找人家，人家不给解决:"因为我们是大平台，我们肯定没错，错的肯定是你们。就算真的是我们错了，我们也不会承认。不然出了PR(对外纰漏)事故我怎么担得起！"
因为他们死鸭子嘴硬的特点，就更容易出了问题就觉得是他们出问题了。但是他们不承认也不解决。与其抱怨内耗，不如做补偿逻辑来解决。像这种管理员丢失，我们是能收到通知的，那我们就在收到通知时重新设置管理员。
甩锅型
在《性能之颠》这本书里介绍了一种责怪他人讹的错误方法。使用这种错误方法的人随处可见:系统出问题了。出问题的地方涉及和其他方的交互，那就假定是其他方出问题了，把问题交给其他方。如果其他方证明不是自己的问题，就再找到一个交互方，把问题抛给他们。
遇到这种合作方，我的做法是在可接受范围内，降低这种问题处理的优先级。并且对于和他们合作的需求，也会排在同优先级任务的后面。
自私型
之前有个同事，自己本地调试就把服务注册到nacos上，因为服务器所在网络和办公网之间有防火墙。流量发到他本地的请求回不来。那就不仅仅是测试服务器查不到日志的问题，而是测试环境整个就挂了。
每次跟他说，他当时停了，下次还起来。告诉他有个参数可以配置启动时不注册，他也不听。
这种情况下千万不要和他起正面冲突。群众的眼睛是雪亮的，你认为他不行，别人也会觉得他不行。时间长了，大家都在统一认知上，这种人会被孤立，自己也会没意思的。没准自己呆不下去，自己就离职了，耐心等待就好。
