@y1y1

还有阮小二和阮小五。

https://www.techempower.com/benchmarks/#hw=ph&test=plaintext&section=data-r23


你看，python 框架还能跑第一呢

好几个故人哎。

你完全不用担心，老板和你看法一样，我们要多多利用年轻人的冲劲。

@Bazingal

请问：假一陪三是赔三个真品还是假品。。。还是赔钱？

你自己都说了，所以我能想到的办法就是：

生成一个指定过期时间的 license ，应用程序启动时检查 license 。

投 trae 一票，因为只要 0 ￥

@hancai2

如果大多人都掌握了，那么就不是艺术。。。

比如视频拍得好，人少的时候称作导演，人多一点可以成为短视频创业者，如果人再多一点就不值钱了。

@zjsxwc

对于大多数人来说不会搞艺术，只会洗碗洗衣服。

trae 怎么还没更新呢

大名鼎鼎的 git 也有这个问题啊。。。。

你搜索.gitkeep 用途试试。

@mark2025

还是有不通的，单体服务你不知道这个接口别人用了没有，界限是模糊的。
而微服务你已经明确定义了哪些是外部的，哪些是内部的。你动内部的，是没有问题的，你动外部的，你需要做兼容处理，或者增加一个新的接口，或者发布一个新的版本。

看看我的需求：

1 ，解决耦合度增加导致的复杂度增加的问题，采用微服务可以物理隔离各类模块的联系。
2 ，微服务后可以按模块部署，更容易按需迭代扩容。

从维护角度分析：
复杂度管理：微服务虽然看起来更多了，但是出问题的时候就更容易定位了。
水平扩展性：性能问题更容易定位，也更容易扩展。


从写代码角度管理：
写代码时由于粒度更小，更加容易写出稳定，可测试的代码。
开始项目前必须考虑通信，性能等因素，进一步要求先设计后编码，有利于提高代码质量。


为什么要微服务？回到第一性原理回答：

1 ，因为人的脑袋存储和 cpu 不够大，不能同时装下那么多模块的逻辑；
2 ，因为一台或者几台机器不够，不能同时运行这么多服务；
3 ，因为我们需要保证服务的不间断运行。


为了看看我的答案怎么样，我问了下 deepseek r1：为什么要微服务？用第一性原理回答

结果还好，无明显遗漏。。。

@dyyhobby

最近一个项目打算转 go 了。因为业务今年到去年增长了 10 倍。

使用 go 是因为想搞微服务，主要解决耦合度增加导致的复杂度增加的问题，采用微服务可以物理隔离各类模块的联系。
另外微服务后也可以按模块部署，更容易按需迭代扩容。

滴答清单年会员你值得拥有

不可能的，牛散比清北概率小。

概率上：几十年出了几十个牛散，和中彩票差不多。

我鼓励我们前端对于设计和产品的不合理和不美观，互相反馈(ds)下。

而且你看的不是一个级别东西。

react 是一个主要面向开发者的库，专注的是开发体验。
request 也是一个开发库，专注开发体验。

这两个东西需要文档。。。


git 包大部分代码专注于数据结构和流程，体验在命令行接口那块。