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

简历求拷打，有没有大佬给点建议😭实习经历不太会写，大部分都是做业务功能的没有很强的技术点😟

鼠鼠体检有以下异常，请问下各位佬需要复检吗，还是说会直接pass掉呀😴

1.自我介绍2.手撕 lru（多了一个x秒自动过期）3.刚刚的代码哪些部分在并发环境下会线程不安全，如何解决4.拷打项目5.有没有大模型微调相关经验6.Redis为什么比其他数据库快，为什么加载到内存会比硬盘快7.刚刚提到了上下文切换，什么是上下文切换，具体是干什么的8.Redis除了分布式锁还能做什么9.Redission看门狗机制10.如何使用ai coding的11.如何学习新技术12.反问lru写的太慢了没完全写完，面试官让讲了一下思路就给过了。但是线程不安全这一块回答的有点磕绊。当天晚上约二面。