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

绷不住了

遇到一个民科乐子，最难绷的一集。

自我介绍。使用 new 关键字创建对象时，一般会执行什么过程？如何判断对象的某一属性是自身的还是从原型链上继承过来的？有哪些方法？你如何理解闭包？实际开发中有哪些典型应用场景？给出事件循环代码，判断执行顺序并解释原因。实现一个带并发限制的异步调度器，说明构造函数、add 方法、run 函数的实现思路。Vue 3 中 Ref 跟 Reactive 的区别是什么？Vue Router 的权限拦截是怎么做的？Vite 跟 Webpack 有什么区别？有没有尝试过写配置优化打包速度或构建速度？开发过程中遇到代码冲突时，如何处理？状态码 302 代表什么意思？对话平台对接的是什么模型？为什么使用 SSE...