记忆错乱肯定会有的，举个例子就是 A 语言的关键字或语法，和 B 语言的关键字或语法搞混了。

解决方案我觉得全靠 IDE 的自动提示把。 但是像一些语法比较灵活的脚本语言，我觉得大概率是避免不了的把。

赞同楼上，翻一翻语法速查。

@effort 这个就相当于 AI 模型的 GitHub

前端加密只能防止一些门外汉（不过像登录账号密码等，可以考虑加个密）。 专心搞破解的，前端加密没啥用。

你说的那种抓不到 xhr ，大概率两种，一种就是服务端 渲染成 Html 直接到浏览器（比如 nodejs 服务端 和 古早的模板引擎）。 还有一种就是它走的是 JS ，再 某个 JS 文件中包含了数据，然后渲染到前端界面。

@poupoo 嗯嗯，只是没接触过。 我学习能力还是挺强的。

总感觉各种协议要求有点多。 云原生这块接触的比较少，FreeSwitch 、OpenSIPS 、Kamailio 、Asterisk 一个都没听过。 上海的话，岂不是得 50 起步？

@LieEar 但凡我可以写出来一个这样的，我觉得我的作品已经属于大厂核心团队的那种了。 可以定制（魔改） JDK 之类的了。 干嘛还面这个试。 哈哈

@kingofzihua 牛逼。 一般来说 rebase 和 merge 混用，尽可能避免出现极多层的 merge 嵌套（原因的话，可以问问 AI ）。 一般 merge 我个人觉得最多 嵌套 2-3 层。

@fields 以后有机会试试。

@fields CI 应该不能 规范 GIT 的操作吧？ 我了解的可以再 Git 中集成 代码扫描器，，如果代码扫描器 扫描的有问题，GIT 就会提交失败。

@Fleey 牛逼了，你这个 merge 也太多了吧。


@fields 是的，后续强调过 尽可能 避免这种，不过很多人都习惯了。


@beyondstars 嗯嗯。 我个人习惯就是走 rebase 的，，不过 很多人都不习惯 rebase 。


@w292614191 嗯嗯，，看到过楼下的那个，，，，确实我这个不算啥了。

你说的问题我也碰到了。 并且你发的一些都是网上能查到的，我都试过。

最终的解决方案，是 Windows 的更新里面的一些补丁安装之后，就正常了。

应该就是如 楼上说的有原因。

@sujin190 字段删掉的话，bean 就不 copy 字段，至于改字段类型，我是做了转换工具去转换得，总体上还是保留 不报错。 但是类型不一致是可以报错的，只是这些工具在实现的时候的考量可能是不报错。

反射就能做到，用反射、Cglib 都封装过 bean copy 。

试了一下，明白你的意思了。

```
List<? extends Animal> list = new ArrayList<Animal>();
list.add(new Dog());

Map<String, ? extends Animal> map = new HashMap<String, Animal>();
map.put("str", new Dog());
```

会出现错误：“
add (capture<? extends test.bean.Animal>) in List cannot be applied
to (test.bean.Dog)”


感觉无力解释，只能说 ? extends Animal 不应该用在这个位置。 一般来说可以这样用，表示可以传入一个 list，可以是 List<Animal>，可以是 List<Dog>，可以是 List<Cat> 。
```
public void takeThing(List<? extends Animal> list);
```

如果需要 List 中可以同时存入 dog 、cat，直接这样就行了。
```
List<Animal> list = new ArrayList<Animal>();
list.add(new Dog());
list.add(new Cat());
```

绿米空调伴侣 还把我家空调弄坏了呢。 （可能有功率限制，但是在怎么限制 普通空调应该得支持的，我家是 1P 的空调）

我觉得如果是单纯的业务系统中的业务代码部分，大概率很难碰到。碰到的话，因为思维惯性，也会考虑 if else 方式解决。 我之前碰到过一个 根据传入的 Code 走不同业务的需求，if else 也能解决，策略模式也能解决。大致就是业务代码中设计模式很难碰到，碰到了也是惯性的 if else 。

不过如果写的是 框架代码，每个公司都会有的自己的框架包的那种代码，那里面出现涉及模式的概率比业务代码大得多了。

@xiaomingVTEX 对于这位兄弟摘录的面向对象封装这块我觉得没有任何问题。

但是如果到了具体的业务场景的时候，我觉得可以 分为 偏业务实体 和 偏数据实体。这位兄弟中的 setPassword 我觉得属于数据实体的范畴。而 changePassword 属于业务实体的范畴。并且这类业务实体，偏向充血模型（即将具体的业务行为放入到实体中）。本人作为 java 开发，java 中的实体偏向贫血模型（即实体更偏向于作为数据的载体，具体的业务行为不放入实体中）。

至于 getter/setter 问题，反正 java 开发者必须写，除非你不打算用主流的框架。至于好处嘛，除了之前一位兄弟说的断点时可以监控外。 另外的作用就是 可以 在方法内 增加一些业务逻辑（尽管 java 中不建议这么做，但是对于一些紧急的需求修改上，可以临时的快速的搞搞，比如某个数据变形、裁切之类的，由于调用点很多一个一个改不方便，直接改 setter 中的内容，或者 getter 中的内容即可，前提评估好影响）。当然在 spring 等很多框架中，一些内部类或者包级别的类，可能有不少就直接 user.name 这样使用的。

@zzl22100048 本质上都是用来做 三方登陆 的，都可以说是属于 认证 把（应该把）？。 OAuth2 第一步是 授权，第二部 根据 access_token 获取用户信息，不就算是 认证 嘛。 oidc 第一步 就返回了 id_token，而 id token 又包含有用户信息，所以称为认证。

首先 阿里云 确实有 JWT 的应用，这个让我确实很高兴，毕竟终于见到 JWT 的大厂的应用场景了。就是 @a728976009 说的 oidc 。 https://helpcdn.aliyun.com/document_detail/93698.html

然后 了解了一下 oidc，感觉 OIDC 和 OAuth 的不同，就是 用 JWT （这里的 JWT 指这种机制，毕竟不同的签名 /加密名称不同） 来做了 用户基础信息 的载体（比如 用户 ID 用户名称），用户的其他信息 还是需要 调用接口去取的。然后因为 OIDC/OAuth 都是用来授权，或者三方登陆的，没有普通业务场景那么多问题，直接 JWT 传过去来获取用户信息就好了。

优势，原来 OAuth 需要 先获取到 access_token ，再去调用 接口 获取用户信息。 而 OIDC 直接 返回了 id_token （ JWT ） 和 access_token （可有可无看服务商），对于大部分 只需要 三方的用户 ID 和 用户昵称的 场景，这样一步就够用了。

至于用 JWT 去获取用户信息这个场景，本来服务于三方授权这样一种业务，你不可能说为 access_token 之类的 还设计什么角色、权限、接口权限 之类的 rbac 那套玩意，毕竟三方授权对于调用者来说我仅仅需要该用户在你网站上的部分用户数据。所以 JWT 的方式其实相对来说 优于 类 session id 模式。

而且那些把 JWT 用来业务系统中的一些问题，比如基本上都不会出现。

我们的 分布式 应用场景，就是由 认证授权模块 统一生成一个 类 UUID 的 token，用户登陆成功后，返回给前端，反正前端看着保存呗，别弄丢就行了。 然后每次请求的请求头 都会带有 这个 token，至于多域名跨域问题？ 后端配置哪些域名可以进来就好了。

流量 -> 阿里云 LBS -> 业务服务器 Nginx -> 网关 （校验 类 UUID 的 token 是否合法，是否有访问这个接口的权限）-> 业务模块 （获取用户信息工具 根据 token 获取用户信息，并存入 threadlocal ）

如果用户信息存入字段，仅仅存入比如用户昵称几个字段，业务上不一定用得到，还得去查一次，如果都存，一些业务的用户信息敏感不敏感先不说，单纯数据量，就很多，上面的 获取用户信息我们设计的也是分段获取，即你要一个用户属性，会自动拉去一定的用户信息到 threadlocal 中，不全部拉去因为多，也不能保证都用到。

是，jwt 是减少了 网关层面的 一次查询，也仅仅是 token 合法性校验的查询 省去了，但是 接口权限 校验还是要查的把。后面业务模块中获取用户信息大概率还是要再查一次的把。所以呢，JWT 最后还是变成了一个 类 session id 的东西。

至于水平扩展，网关受不了了，加机器。业务模块受不了了，加机器。注册中心大概率不会受不了的。 想怎么加就怎么加，只要有钱就行。

如果 jwt 真的那么好，那么你们会发现 各种开放平台，比如 微信三方登陆，阿里云的各种接口等应该都走 jwt 才对。 然而并没有，他们的 appSecret 也好 accessKeySecret 也好，没有一个走 JWT 的。 他们的量级够大把，他们的开发团队够强把，如果这个机制（ JWT 的思路，毕竟大厂，也许会自己造轮子）真的好用，他们应该会用上才对。

看看微信的 三方登陆，拿 appId 和 appSecret 去换 access_token （类 UUID 的字符串，其他参数不管）。然后其他接口比如 获取用户的信息的接口，是需要传入 access_token 的（这不就是类似于 session id 的机制嘛）。

人家大厂还在用类似于 session id 那套，等哪天各种 各类的技术博客啥的（比如 美团技术团队 那个博客，还有一些大佬的博客）都强推 JWT 了，再考虑 JWT 把。