垃圾优衣库，我线下买的 249 一件的帽衫洗了两次后质量和 100 的淘宝货看齐，质量太差了

想钱想疯了，我几个月前试过 evernote ，感觉这玩意跟不上时代了，文字编辑的能力很弱

劝女孩学码真的不太行，主要是编程实际上还是很繁琐的一件事情吧，我读书那会班上的女生纷纷弃码从研另找出路，我问过其中一个女生，她就吐槽说编程要同时学会用十几个软件（或者网站），看着就烦。

所以如果楼主想从兴趣上入手给人培养还是算了，编程这个事情很多时候并不有趣，本质上是很高强度的一种学习

忍不住想说两句。

Chatgpt 我也在用，但是关于实践性的、抽象的问题回答能力太差。它顶多给个客观答案，比如说这里可以这样这样做，并且多数情况下是正确的，然后呢？这种做法是否适合实际情况、有没有坑、是否在团队合作中被大家认可？ Chatgpt 表示不知道，它就是个无情的知识机器罢了。

上论坛提问、看论坛帖子，更多求的是"经验"，很多问题是在讨论中解决的。"社区经验"、"工程共识"，无外乎是。

-------------
另外还有一点就是上面 V 友也提到了，很多问题 OP 觉得"问 ChatGPT 就知道答案的简单问题"，真的对很多生手就是一个门槛，没人点醒真的就是"只在此山中，云深不知处"，在这点上 Chatgpt 是真不可信，甚至可以给出完全错误的思路。总之，社区还是尽可能多包容一点。

瑞幸 9.9 ，不为啥的，瑞幸的咖啡喝起来像奶茶，速溶什么的没有这种味道😂

java 初学就是这点很烦，这些个 O 都是人为规定的，熬一段时间熟了

支持，平常还真用得上

支持支持

支持，有空试下

@kloudmuka 简直就是拉低整个就业群体的信用度

@wyx119911 1. 思路不错，感谢； 2. 可以考虑。并发指的是同步并发还是异步并发？这种内部业务逻辑要求即时处理数据的场景不能使用异步吧。

@lsk569937453 项目要求，不得不上，当时选取微服务架构的原因就不是技术因素

@ZZ74 #19 “内部调用何必呢。” 是的内部调用没有必要鉴权，现在问题是暴露出的所有接口都是面向外部调用设计的，例如说 api 方法签名里包含请求参数 appid 、userid 、sign 、time 等，就没考虑内部调用的场景，导致现在内部调用都是先拼接参数字段再发起请求，和维持一个外部用户 agent 没有区别。所以现在是想绕过这些已经定义的 Restful api 去进行内部请求，但是没有思路。

@lanlanye 2 首先肯定是设计问题，然后又由于 1 加剧了状况，需要写大量的冗余代码拼装请求去进行服务调用，响应时间还很长

@4kingRAS #13 霸王硬上弓，上面有意通过这个项目积累团队开发微服务的经验

@teble 应该这么做，但是开发前期团队其实脑子里都不存在微服务网关这个概念，所以采用的是每个服务单独调用鉴权 SDK 包来实现鉴权，实话说就是单体应用暴露 API 接口的写法，认为每一个暴露的 API 均为外部调用。后面虽然加上了微服务网关，但是之前写的 Restful 接口签名已经很难改了，要改的话等于重构，那就是下一个开发周期的事情了