其实已经有影响了，不然微软也不会那么着急入场。只是传达到生产力末端还需要时间。

R1 写代码不如 V3 。再者就是温度要低。

目前的大模型普遍写前端和 python 很强，主要是训练代码的原因。

至于你说的：“写完代码之前，我都不知道整体的思路会是怎么样的”，是你工作流程有问题。

把你的问题拿去问 deepseek R1 ， 给的答案比评论区大部分方案靠谱。

说的很中肯。但评论区抬杠的不少。

op 是用 oracle 的？

胡说八道。这行业谁能躺在功劳簿上不动如山？不开辟新的商业模式等别人做了把你竞争死。

可以说具体的：“做某个方向可能错了”，但不能说主动做这个行为错了。

点赞！
但 java 现在几乎是一个纯工业语言，灵活性相比 其他新兴语言差一些。在 java 里追求灵活性的各种魔法，反而会抛弃 java 相对严谨的语言特性。过于复杂的 SpEL 表达式不是一个很好的方案。

能上 V2EX ，去 gpt 问问也有答案了啊。

语法层面的问题都不是大问题，大不了用 scala 、kotlin 。
Java 比较难改的是 JVM 层面的问题，比如：1.对象的属性是链式引用，没有结构体，在绝对性能场景下是劣势。2. 引以为傲的“一次编译到处运行” 、JIT 等技术在容器大时代下已经再不重要；启动慢、占用内存大的缺点被放大；等等。

换句话说，从生产角度讲，语法糖是无关紧要的；但 JVM 在现代场景下的劣势是所有 JVM 语言都要面对这些问题。

如果有一天 Java 被完全淘汰，那一定是 JVM 被淘汰了。

你的业务场景描述的不够清晰，日写入量多少？ qps 多少？
按你目前的需求，举个例子，不一定精准：你可以按天分表，几千万数据 1 天 1 张表也是完全 ok 的。

异步方案并不意味着延迟啊，下游消费跟得上就没有延迟。
如果消息产生了积压，你不异步的方案估计已经挂了。

比如消息队列异步，做一个单独的服务来消费，这个服务可以根据数据量任意扩容缩容，不用改动主服务。主服务写入消息队列后就返回。很常规的方案了。

分库分表策略，和分表后的插入效率，是两个问题，不要混在一起处理。
批量插入效率的忧有其他方式可以解决，但数据库设计后期很难打补丁了。

异步的方案上面的回复都给出了，大差不差就那些东西。
异步的问题无非是数据更新有延迟或不同步。理论上业务肯定有优先级，不必做到 30 多张表全部实时。如果还是有疑虑或者业务方要求必须实时，可以在异步的方案上加一张 patch 表，配合异步方案对这些表的查询结果用一个拦截器做实时补偿。

google 有个开源项目叫 diff-match-patch

我用 2022.2.1 版本 卡的一批。换回社区版后一切正常。可能是 idea 的问题。