被挂了，希望发出来对大家有帮助！1.实习拷打2.项目是怎么来的3.秒杀业务的库存/优惠卷是怎么来的4.对业界中的库存怎么做了解过吗?5.项目中的存储方案是怎么设计的 ?6.分库分表怎么设计的7.订单号耦合用户 id 作为分片键怎么做的? 这些做有什么问题 ?8.接口可用性和幂等性是怎么做的9.有从 0 到 1 掌握一项技能的经历吗10.这个过程有哪些阻力11.java 线程的生命周期12.用线程池做了哪些实践13.事务隔离级别14.不同隔离级别分别解决什么问题15.遇到过死锁吗 ? 什么情况会发生死锁 ? 如何解决死锁 ?16.使用 ai 解决过什么问题 ? 和普通编程有什么区别 ?17.选一下手撕代码 还是 ai coding18.手撕第 k 大的元素

1. Agent 和传统 workflow 的本质区别是什么，什么时候该选 Agent，什么时候不该选传统 workflow 的核心是路径预定义，系统知道每一步做什么、怎么流转、失败后怎么回退，所以它更适合规则清晰、链路稳定、审计要求高的场景。Agent 的核心则是把部分决策权交给模型，让它在运行时决定下一步查什么、调什么工具、如何分解任务，因此更适合任务开放、输入噪声大、解法不唯一的场景。真正的分界线不在“有没有模型”，而在“是否允许运行时规划”。如果目标是工单分类、审批流转、固定字段抽取，workflow 往往更稳；如果目标是复杂排障、代码仓库理解、跨工具探索式分析，Agent 才更有价值...

测开简历投的客户端，实在是烂麻了，手撕反转链表和合并区间问了一个url页面显示过往项目中能展现自己的点对客户端和服务端的看法，未来职业发展的规划。

1. 自我介绍2. RocketMQ 里顺序消息、普通消息、事务消息分别适合什么场景，为什么不能混着用普通消息适合最终一致、无严格顺序约束的场景，比如日志分发、画像更新、通知投递。顺序消息适合同一业务键必须按时间线推进状态的链路，比如同一工单、同一订单、同一会话的状态演进，但顺序消息的吞吐和容错设计会受到队列粒度限制。事务消息适合本地事务与异步投递之间要建立“发送承诺”的场景，比如主库先落事实，再由 MQ 推动旁路索引或下游补偿。三者不能混着用，是因为它们解决的问题不同，消费模型、失败恢复方式和成本模型也完全不同。3. 如果 RocketMQ 出现消息积压，你会怎样定位，不要只说“扩容消费者”...