？？？改什么吃屎，不是一直在吃？

再说，不会有人以为不会走百度的老路吧？不会把不会吧？想什么呢。真要没限制的去用 oss

1 、组件不符合需求就自己写一个。组件库只能覆盖 70%的场景，选一个自定义程度高度组件库就行，element 和 ant 耦合度很高，建议要用这种库的话就优化需求以符合组件库即可。
2 、好好学。

这不就是 nest 么。。。

谁的码合一了？

@JL1990 #7 那为什么不把字段都做在一个 struct ，然后再判断那些有值不就行了么？

https://s2.loli.net/2022/01/15/4f1JIzoFEKeDp8g.png

@ZztGqk #11 不在工信部备案的网站“按理”都不能打开，这不是我决定的[doge]。所以被墙了毫不稀奇。还有博主说想反抗😄，建议先开个群大家都加进去反抗。反正到时候谁先进去我就不知道了

分别解析 V1 、V2 不行？你写的这个 parse 和直接调用 unmarshal 有啥区别

太快了。不习惯

很稀奇么？

@hhjswf 这看你业务来着。我自己预想的是订单这个整体是一个服务

@linglin0924 #89

我认为是因为 lz 习惯了 bookinfo 一股脑带出来可以直接渲染，页面不用太多异步逻辑，加上以前单服务的时候是可以 join 起来也方便，所以直接返回也没什么问题。这是 ok 的，因为那时候大家都这么做的。

但是到现在新微服务架构后，两个服务分开了，分别提供了 curd ，就没必要再加一个聚合的 bookinfo 接口，因为确实没必要。

这个构架不用考虑握手太多的问题。人少对系统没压力，人多接口分细了反而能降低系统负载，前端也可以用中间件做 ttl 缓存。问题很好解决，或者说压根不是问题。

时代变了呀~

@wupher 他这个已经是微服务架构了。不同业务直接不要直接操作，更何况在不在同一个库都不一定

@wunonglin #41

网站人流量多的可以在前端用用中间件做 ttl 缓存，网站人流量少的你也不用考虑多次请求带来的负载。

每个模块都有 curd 了，那就没必要再给你搞一个聚合接口，你说可不可以，当然可以，只是没必要而已。

两者都合理，具体还是看业务场景。

但第二种明显更好，毕竟你是获取 bookinfo ，其他东西没必要带给你，你再根据 bookinfo 里面的外键 id 去其他对应的接口查询即可。

这样的话再根据各个客户端的需求，去做就好了。比如页面需要一次性显示，app 不需要，那这样接口拆分的就很合理

再者就是可以“渐进式显示”，打开 bookinfo 页面，先显示 bookinfo ，然后再去请求 order ，这样用户就能先看到页面，不至于要等全部数据出来才显示。

比较复杂的例子：一个 bookinfo 里面，可能有 tags 、orders 、images 、comments ，如果全部给你，数据多的话体验会很差。那我可以先显示 bookinfo ，然后再根据用户点击的 tab ，再去加载对应的数据（懒加载）那体验会好很多，这样系统负载也会小很多，毕竟可能有的用户只是想某几个模块而已

人家把你当傻子，结果你真以为是概率问题？就算这问题过了，还会有下一个破下线的，认真你就输了

放~