@dengkj #117 合着女的是雌雄同体能自己生孩子？

@sagaxu #16 方案是好的，但是执行起来变数太多了。

首先别看天府大道那么宽，实际上上下班也堵的厉害，要选挨着地铁的才能缩短通勤时间，另外考虑娃上学，天府新区的教育资源肯定不如老区。

@xuelang #1 这个科普写的真好。

@shadowyue #88
这就有点过了吧，怎么大家都是草包了？
你那个帖子说明你对跨域停留在简单理解上，并没有太多实际业务中的跨域边界问题实践经验。

@dongzhuo777 #69
主要是单体的话，靠日志在本地或者测试环境复现的难度小很多。
如果不是微服务，而是某个模块，那我可以直接 debug 一步一步调试就可以，也可以做各种 mock 方便我复现。
但是微服务的话，拿着各种服务的日志做对一堆服务做排查，还会碰到某个服务是完全不同的语言写的，这一下子时间成本就上来了。
单体就像是独立开发，微服务就像是多人合作，上下文切换和沟通成本变大了。
确实你说的没错，日志的问题换成单体也会碰到，只是单体相比起来排查起来更容易些。

前面有人说加上链路追踪，日志搜索平台就可以，然后你会发现：
1. 这个全链路追踪的性能消耗为啥比线上所有服务的资源消耗还要大，最后只能改成只用 traceID 做记录，那种有详细记录的链路追踪就算了吧。
2. 服务太多，排查基本全靠日志，要是出现一个问题没有被日志覆盖到位，改代码，加日志，上线，诶，好像还不行，还得加日志，来来回回整半天，而且有的问题只有等加日志后复现，不然你永远也不知道为啥会有问题。
3. 日志加多了之后，每天的日志量很大的，一天 1TB 的日志都不是问题，日志越多，日志平台的性能消耗就越大，这时候用 ELK 的成本可能比你当前线上服务器的成本还要大。
4. 服务太多，本地调试困难，别说有测试环境，真实情况下微服务那测试环境每天都是缝缝补补，谁用到的时候谁去修，修复测试环境的时间比你开发需求的时间还要多的多，想想几十上百个服务的部署，启动顺序，数据库数据，业务依赖，这测试环境的部署和维护就足够麻烦了。

你看上面这些问题，除非是大公司有钱玩的动，小公司还在天天计算如何优化服务器配置减少成本。
最后，定位一个问题两天一夜其实也说明不了啥，有些问题工单一两年都查不到原因，但是查不到也没关系，可以用别的方式想办法规避开。

没太看明白，意思是说个人最优解是进入一个其他同事都比较全能的团队，自己或者同事会不会都不是问题，只要团队里能有人会就行？

@whoosy #13
兼容的话，不管是新增错误码，还是用子错误码还是别的方案，要做兼容都是搞一套新的或者加新的，旧的不动，继续留着。

@magicZ #1

在响应附带身份凭证的请求时（通常是 Cookie ）：

服务器不能将 Access-Control-Allow-Headers 的值设为通配符“*”，而应将其设置为标头名称的列表，如：Access-Control-Allow-Headers: X-PINGOTHER, Content-Type

服务器不能将 Access-Control-Allow-Methods 的值设为通配符“*”，而应将其设置为特定请求方法名称的列表，如：Access-Control-Allow-Methods: POST, GET

抛弃用 int 来定义 error code ，用字符串，用 . 来表示业务层级关系，比如：{ "error": "order.edit.network_error"} {"error": "order.edit.no_auth"} ，既表意，又能扩展，也有层级关系。

跨域的问题不只是原理，你以为理解了，MDN 那个文档看过无数遍了，但是每次和前端对接都会出现新的问题，xhr ，fetch ，axios ，不同的库对 cors 的使用方法和处理方式不同，烦人的很，而且现在的跨域限制的更多了，以前能行的办法突然发现某些情况下又不行了。

@tangkikodo #27
如果是前端来维护的话，那谁维护谁倒霉。
本来前端只需要负责渲染层就行了，现在额外维护一个服务端的服务，图什么，直接拿后端的接口组合转换数据就好了呀，你既然能用 node 在服务端组合数据了，那也就一定能在前端组合数据不是么。这要是线上接口出了问题，本来没前端事的，维护的那个人现在也得爬起来跟着去修复，我上面回复的 bff 可以直接替换成维护的人。

@tangkikodo #23
bff 既要对接前端也要对接后端，那就是干最脏的活拿最低的绩效，线上出了问题，bff 还得第一时间想办法自证不是自己的原因，前端后端只需要一句是 bff 的问题就完事，bff 要做的事就多了。

BFF 就是两头受气层，最适合背锅。
还有 GraphQL ，并不会让工作量减少，甚至会变多，前端后端都不待见。