HyperionX

其实就是后端的一些编程过程导致的：可能存在状态扩展的是 1/2/3 ，数据库存了的是 0/1 ，手搓了业务逻辑的是 true/false 。以前大单体时代一堆接口可能还有一个项目框架限制一下，现在微服务时代基本处于管不了的状态。就算这种通用中间件可能 A 项目用 1.0 ，B 项目用 1.1,C 项目用 3.0 。大部分情况下为了通用性和适配调用其他服务的弹性和自适应，返回的信息基本都是透传，项目内可能压根就没转换过，json 的序列化和反序列化还是比较消耗性能的。
前端的一个项目往往由后端一堆项目的接口组成，经常跨语言跨项目组甚至跨部门跨公司，技术规范都有较大差异。这是分化带来的遗留问题，同时也带来了机遇和挑战。
如果作为前端感觉经常对接一群后端，他们组还不一样，可能收口就在前端，最好自己做 bff ，沟通成本会比自己实现高得多。如果经常只有一个后端对接或者后端就是个单体只给你们提供接口和服务，催他们 leader 写个统一的规范也是应该的。

吐槽没堆栈信息的是都不用 trace_id 吧。不用 go 的生态只单用 go 语言，有不契合当前熟练语言的生态东西和思想，引发很多吐槽确实很常见

lativ ，台湾品牌，质量还行。不过优衣库和 muji 都可以等节日四折

你要是刷题的话应该知道把，最基本的数据结构，大一大二就学。

@anmie 既然知道自己没怎么干活就不要瞎评价工作量好吗。。。。产品挑战你工期说你就一个页面一天别人一天能干完你怎么要七天，你啥感受？

老家除了 java 和 php 没得选吧

@rimutuyuan 正规企业都是再招一个好吗。。。。

刷题少了

bGF6eV9wYW5kYS0z 加我可内推