qingyingwan

看起来感觉是工作经验比较少的前端。我当年 react 一两年经验的时候也经常纠结这种代码细节。现在做后端了，也遇到过这种纠结细节的，各种规则一大堆，代码 pr 要一周。结果核心的服务性能，延迟，稳定性，可观察性，架构设计都是依托。

想搞远程最好发展下全栈能力吧，一是沟通成本低能一个人搞定某个业务，二是机会更多

这个老板挺抽象的。不是自己人的同事出了事，不管代码错误还是事故，一定要当着老板或者领导的面提出，别私聊。私聊解决那是信得过的人才行。比如你这同事，就适合在大群里面直接叼他，温和一点的就在群里现场给他指导。
之前我就遇到过这种同事，啥都不会还在那装逼，我直接顺着他，然后出了毛病我直接截图拉老板和领导叼他。后面被辞退了。当然关键是老板信任谁，老板不行无解，只能躺平找下家

@v2exgo 这不算核心问题，九成靠经验吧。真实业务场景极少遇到的不算核心，只能说刁钻。反正我大厂高并发后端深入技术干过，创业公司全能后端也做过，没遇到过一次。各种成熟的三方工具，比如想的方案厉害多了。深究细节的话，比如你去研究下 mysql 的架构和源码，即使只读懂一百行 C++，也可以直接问倒任何考八股文的面试官。再比如，内存屏障，原子操作，在各种 CPU 架构上如何实现，这种细节随便都可以问倒一批人，我马上查一下就知道了，但我知道这些，也并不比不了解的答主厉害，因为他也会搜索会问 ai 。

LLM 是数学期望和概率预测吧，有两个致命硬伤。一是训练资料的正确性，时效性，资料有限，注定训练的模型能力是有限的。 二是训练算法和计算能力有限，人类对世界底层的理解直接决定了算法和算力的上限，连自己的大脑都没彻底搞懂，说白了智能的定义都没搞明白

前端的上下文：组件，接口，数据，页面，用 cursor 简单又直接
后端的上下文：数据库表结构，缓存结构，消息队列，es 索引，rpc 上下游，各种定时任务，触发器，代码逻辑只占复杂度的三分之一不到。看个文档都要半天才能理解架构，你说 cursor 怎么理解上下文

@qingyingwan 场景三：某个业务要求全流程的日志记录，或者精确的 metric 上报。服务端：各种高可用的架构支持。放在前端：上一秒点击付款，下一秒关闭浏览器或者断网了，啥数据也没有
场景四：需要事务的时候，服务端能做到分布式事务。还没见过业务的事务放在前端。
深入服务端或者全栈就知道了，java 八股文没法成为前端八股文，就是前端解决不了那些问题

第一个场景：现在商品 A 的价格是 100 元，想上调到 300 。服务端：分布式动态配置，或者 apollo 之类的，锁库存，改价格，几秒生效。浏览器：本地静态资源缓存，cdn 缓存，新版本发布两天了还有用户再用老的 gitVersion 版本，业务跑不动。客户端：同样的道理，版本更新了没法保证立即全量。解决办法也有，前端业务做一个版本判断，但不太现实
第二个场景：一个接口，需要访问两次消息队列，三次 redis ，四次数据库，五次 rpc 调用，服务端内网是毫秒级延迟，保证分布式高可用。放在前端：寄
服务端可以做到对代码，流量，数据，运行环境的完全控制，前端写一些不重要的业务倒是没啥问题

@ugpu 都不是大厂，中小厂