相比于代码，我觉得更复杂的是各种意义上的环境
依赖库的环境，工具链的环境。。
我现在往往觉得，写业务代码是简单的， 修各种难评的脏乱差环境是巨大的时间和精力消耗

个人小项目我用 hertz ，可以 thrift 或者 protobuf 生成代码🤔

小型项目也能用 zed 写，感觉速度不错

用的并不高频。一些工具类用的多一些，字面量转指针之类的。。
和 Java 比，类似 Result<>用得并不多。。。

我在 vivo 上用 via 浏览器，大概率可用，passkey 不好说…

道理是这个道路，有时候不如像大妈一样果断进场出场

@littleJohn 我是交易所 usdt 买 sol ，手续费是千一。 如果搞 maker 单还能更省，量不大不用纠结。直接市价买入。

然后用交易所提币到 phantom 钱包，手续费 0.001sol ，rmb1 块多

一次学习全量知识和逐步学习增量知识的难度是不一样的
搜索引擎上良莠不齐的资料也很多
love and peace

@tangyujing99 这位兄弟是天地会的成员嘛？

@Livid 注册 12 年老用户昨晚也支持了一波，发现大晚上的也有人交易， 求空投一波图一乐=，=

ECgthC8UX53sNPmmztQqcYyTArSMqW7GJssr6wWhsiKm

在用 vivo ， 还以为只是 vivo 比较烂。。。

看具体情况吧， 简单的应勇直接怼简单的表，可能也还好。
还是你的应用的复杂度，在分层和便捷中找平衡点。

想起之前的组件，在 controller 里直接做了非常多的，对于订单表的零散读操作和写操作。
造成后续，梳理需要哪些字段做索引， 哪些字段在什么时候会被更新变得非常困难。。

包括他还在 mapper 层里， 读 ThreadLocal 里的 UserID , 没有 Controller 层里取出来，作为参数透传。。
加上他设计了许多混乱的线程池， 造成串 UserID .. 头疼..
再加上他对使用 @Transactional 充满极大的执念，把很多地方的 TransactionalTemplate 代码改成注解，导致许多地方没有生效，错误信息丢失。

buffer 叠成这样的。。可以考虑 fire 了。。

稍微跑个题，我现在更在意那些和特定语言无关的问题…

考察对道的理解，而不是术的实践。

越具体的问题，LLM 的效果一般更好一些。
而那些宽泛的问题，LLM 给了答案，并不能保证提问人能正确的实践。

都行的，详细一点更好，可以 merge master 的时候合并下 commit

@aarontian 又被提醒到。。确定