好吃，支持

围观围观

很难哎，应该把大模型更多当人来看，就像一个新入职的员工，直接让他按 XXX 口径取 XXX 数据， 他不知道数据不知道业务，很容易取错。


就算带了两年给训练成熟练工了，取相同的数据也很难一口气写个 100%对的 sql 。更别说业务的迭代了

@hhyyd 现在：知识丰富但不保真、能力强大但无主见的。。。孩子？

以前是：冷酷、固执、么的感情、绝对理性的杀手

我鼠标刚过保就坏了，本来想打售后看看咋修，结果没有维修渠道。后来去淘宝上随便找了个店修了一下，效率还挺高。

今天正好看到一张表情包:

一个妈妈，和两个孩子 java 和 c#

妈妈：喊 java 你过来干嘛干嘛

c#: 妈妈你怎么从来不喊我的名字

妈妈： 好的，microsoft java

...... 我 ？？？

碰到过类似问题。我们当时的方案

有直接用 get 传 body （楼上说可能有问题，这个我没碰到不清楚）；

也有直接拼 query ，虽然不好看但是容量限制很大，一般超不了；

还有就是用 post ，个别复杂搜索接口用 post ，毕竟规矩是死的，人是活的，不要被限制死。

首先我认为婚姻是需要双方父母的祝福。其次是你们两个人结婚，不是父母的婚姻。所以你们两个人能不能结婚还是要看你们两个自己，其中解决双方父母的态度也是你们两个人需要共同面对的事情之一。

凌晨 1 点自己家的房间

我做了两个项目的登录功能后，目前的方案是：accessToken 过期时间设置短些，如果过期则前端用 refreshToken 获取新 token 即可（对用户来说是无感知的替换了 accessToken ）。jwt 和 redis 选择一种方案即可，jwt 本身有附带信息解密即可，如果用 redis 关联 token-用户信息查询也很快。

两种方案都有尝试过，相对更倾向加上 redis 去做记录，如果想要在服务端清除用户本次的登录状态，如果有 redis 记录就方便些；如果用的是纯 jwt 的话，不是很好办，最终还是要服务端记录这个 jwt 。

楼主的过期超时 20 分钟的缓冲，其实就是 refreshToken 方式, 刚开始接触的时候，也用过这种 token 替换 token 的方式，后来发现还有 refreshToken 这种方式，非常适合这种频繁操作时延长 token 有效期的场景

之前一个人在外面打工，到周五，就下班出去往人多的居民区逛逛走走，有啥吃啥，人多热闹。回去租的小房子太孤独了。

如果想让这个匹配不到,我的思路是:

自定义 HandlerMapping 在匹配到 HandlerMethod 之后, 尝试一次参数的类型匹配?转换?, 如果匹配失败, 直接让这个 url 匹配不到从而走 noHandlerFound 的逻辑抛 404

不知道是否可行?