你说它刻舟求剑，但是他知道为了避免时间的影响，特意用年份来做变量，因为这个不太容易变，真出了 bug 用户重试一遍就好了，摸不着头脑以为是偶然。他真的我哭死

@WngShhng 这里说的默认的逻辑指的是啥呢？ “不同的对象在内存上分配的地址是不同的” ？ 所以 new A equals new A == false 一定成立？没有这种说法吧。。。record 就不是这样的吗？我觉得你的假设站不住脚

@prosgtsr
1. 实际是存在这样的业务场景的，我可以随便给你举两个例子。
a. 序列化/拷贝/深度比较时的“已访问映射”：oldNode -> newNode 的映射表
b. 图遍历（比如 AST 、依赖图、对象引用图）要避免循环：用 Set<Object> 记录“访问过的节点实例”

2. 我觉得你说的理由站不住脚。

@WngShhng 我还是没太懂，没有场景干说很难理解，你方便具体举一个这种容易出问题的例子，方便理解下吗

> 但我认为的是，因为当把一个对象放进哈希表的时候，我会默认它的 hashcode 方法是默认的，也就是每个对象有唯一的哈希值。如果重写了 hashcode ，那么在使用的过程中如果不知道这个类复写了 hashcode ，那么就容易导致代码问题。

这句话有这么几个误解：
1. “每个对象有唯一的哈希值”，hashcode 只有 2^32 个取值方式
2. “复写了 hashcode ，那么就容易导致代码问题”，只要你不是乱实现，比如 hashCode(anything) = 1, 那不会有啥问题，对于 hashset 的使用场景，冲突了也无所谓（性能会劣化一些），实际会用 equals 兜底


然后重写 equals 必须重写 hashcode, 为啥你可以看下面这个例子就知道了

```java

jshell> import java.util.*;

jshell> class User {
...> int id;
...> User(int id) { this.id = id;}
...>
...> @Override public boolean equals(Object o) {
...> return (o instanceof User u) && this.id == u.id;
...> }
...> // 故意不重写 hashCode() —— 这是错误示范
...> }
| 已创建 类 User


jshell> var set = new HashSet<User>();
set ==> []

jshell> set.add(new User(1));
$5 ==> true


jshell> System.out.println("contains(new User(1)) = " + set.contains(new User(1)));
contains(new User(1)) = false

jshell> System.out.println("equals? " + new User(1).equals(new User(1)));
equals? true
```

然后你如果用过 Record 就知道，调用方不知道是否重写不是风险点，相反它是语言/库的常态用法。

```java
import java.util.*;

record User2(int id) {}

var m = Map.of(new User2(1), "ok");
System.out.println(m.get(new User2(1))); // ok
```

然后什么时候重写 equals: 你需要业务上的相等比较而不是内存地址的比较
比如判断 peronaA == personB, Person(age: Int, name: String)
其实就是比较 person.age 和 person.name 这两个字段

这种情况下重写 equals 必须重写 hashcode ，原因上面说了

简单总结下：
1. 默认 hashCode 不保证唯一（取值空间有限、也可能碰撞）
2. 重写 hashCode 本身不是风险点，风险来自 equals/hashCode 契约被破坏
3. 重写 equals 必须重写 hashCode ，否则 HashSet/HashMap 会出现“看起来相等但查不到”的现象

然后还有一个点：
作为 HashMap/HashSet 的 key 时，参与 equals/hashCode 的字段最好不可变；否则对象放进集合后字段变化，会导致后续 get/contains 失败。

而这些功能和可能踩坑的点 JVM 的 Record （ 2020 年首次 preview ） 都帮你实现了 。作为对比：
Kotiln 1.0 版本在 2016 年作为 data class 的核心关键词支持
而这个功能是 Scala 1.0 早在 2004 年 1.0 发布时就作为 case class 支持了

ff 吗，听说裁了挺多

感觉 idea 已经逐渐 eclispe 化了

@katwalk 举个例子来说，常见的误区，通过对话来问：“你是什么模型”，了解过原理就会知道这是不靠谱的，因为这个不是事实，而是根据语料&系统提示词回答的。再比如楼上有人说去问 ai 自己怎么运作的，这又是一个典型得不到答案的错误提问方式，具体原因不难想

@katwalk 原理还是有用的，你知道 token, 知道词表，那你就可以通过手动替换词表做一些很 hack 的事情，可以为中文定制一个更高效的子词词表，让相同的内容用更少的 Token 表示

有没有合适的用例呢？

《人月神话》：复杂性不会消失，只会转移。AI 没有消除本质复杂性，而是将其从编码环节部分转移到了设计、验证和集成环节，通过 ai 你可以让车子跑的比原来快 10 倍，但车子出问题的频率也会同样增加。

感觉在重新发明编译器和程序员

不支持 format 好，要不然又会有 2006-01-02 15:04:05 手动狗头

我来，10 行内手搓数据库（ bash ）

#!/bin/bash

db_set () {
echo "$1, $2" >> database
}

db_get () {
grep "^$1," database | sed -e "s/^$1,//" | tail -n 1
}

对方如果让在职员工来做证人证言，你可以提出质证：其作为受公司管理的在职员工，与公司存在利害关系，因此其提供的证词，内容受到公司影响，不具有客观真实性，也不具备合法性，因此本人对此不予认可

简单看了下，没理解为啥要弄出来一个 addIndex 后，还要弄一个 addIndexRight, 作为一个“函数式”的库，不应该直接用 map 来实现吗？而且 add 和 addIndex 听起来就有歧义，为啥前者直接就是算数加法，后者就是添加成一个 tuple ?
const arr = ["a", "b", "c"];

const res = Array.from(arr.entries()).map(([i, v]) => [v, i + 1]);

引用下 https://refactoringguru.cn/design-patterns 的一段话：

设计模式自其诞生之初似乎就饱受争议， 所以让我们来看看针对模式的最常见批评吧。

一种针对不完善编程语言的蹩脚解决方案
通常当所选编程语言或技术缺少必要的抽象功能时， 人们才需要设计模式。 在这种情况下， 模式是一种可为语言提供更优功能的蹩脚解决方案。

例如， 策略模式在绝大部分现代编程语言中可以简单地使用匿名 （ lambda ） 函数来实现。

只写 java 的是这样的，建议也多看看其他语言，所谓的设计模式，在现代的编程语言中，很多都内化成语法了，举几个例子：
策略模式：一等函数公民(js/ts)，匿名函数 (c#), 类型类（ scala ）
构造者模式：case class (scala), record(jdk 17), data class(kotlin), dataclasses/pydantic (python ）
visitor 模式: 代数数据类型 (rust), sealed trait + 模式匹配 (scala)
单例模式: 语法关键字支持（ scala/kotlin ）, 类本身就是 (ruby)
Decorator 模式：Decorator 注解(python)

他想要的不是 ai ，是赛博灯神

@MrRongts #12 不懂 rust, 不过这代码丢给 ai 分析，好像也看不过去。我认识的一个写 rust 的大佬说，乱用 unwrap 的都是在代码里拉屎