第一次真正感受到“技术判断”这四个字,不是在写完代码的时候,而是在一次方案评审前。需求看起来并不复杂,业务要上线一个新能力,时间不算宽裕,但链路很长,涉及多个模块联动。导师把文档丢过来,只说了一句:先别急着写,先把可能出问题的地方找出来。 我最开始也和很多实习生一样,下意识会先看接口、看表结构、看怎么把功能做出来。但越往下梳理,越发现这不是一个“把需求实现”就结束的任务。高并发场景下,任何一个看起来正常的调用路径,都可能在流量起来之后变成瓶颈;任何一个默认重试、超时设置、依赖堆叠,都可能把局部问题放大成全链路抖动。 于是我先没动代码,反而花时间把调用链、异常路径和兜底逻辑一条条画清楚。哪些请求...