s1n1an

打印日志，看到 useSession() 在服务端预渲染时，返回始终是 { data:null, isPending: true }，这是对的，符合预期；
那问题就出在 useSession() 在客户端运行，应该是客户端运行时，页面右上角的登录态渲染的比较早，触发了 useSession 并发送请求，此时页面内深层的组件还没加载出来时，然后 useSession 提前拿到返回值了，这就导致后续组件渲染时是已登录状态，与服务端未登录的状态不一致，触发 Hydration Error

@Razio
全部 SSR 肯定没问题，也不会有 Hydration Error ；哪怕用根 HydrationBoundary 把登录状态提前 prefetch ，也不会报错的，我上面就说了呀。

我主要是希望尽可能多静态渲染，只有非 SSR 不可的页面再 SSR ；
右上角那个登录状态，所有页面都要用，所以要是这里用 SSR 来读 cookies 的话所有页面都是 SSR 了，不符合需求；
所以我之前和 4 楼说的一样，右上角那个登录态做成客户端组件，用 useQuery 去查登录态，请求返回之前有个 loading 的样式占位，这一切正常。

现在问题，只要客户端组件多处用到 useQuery （或者 better-auth 的 useSession ，也一样） 来查询登录态，居然能出现 Hydration Error ，这是客户端组件啊，刷新 N 次就能复现一次；如果是上级 layout.tsx 用 SSR 把数据注入 <HydrationBoundary>，那触发的更频繁了，基本刷新 2 次就复现一次。
当然是登录时才有这 Error ，退出登录就好了，刷新 100 次也没 Error 。

对登录 hook 的返回值打 log 发现，如果是这个顺序：A undefined 、B undefined 、C undefined 、A 已登录、B 已登录、C 已登录，这样就正常；
报错的时候是这样：A undefined 、A 已登录、B 已登录、C 已登录，或者是：A undefined 、B undefined 、A 已登录、B 已登录、C 已登录，这样就报错了；
难不成 useQuery() 在预渲染的时候返回值不稳定？如果变的时机提前了，例如在 B 代码运行前就变了或者在 C 代码运行前就变了，就导致后续的若干个组件出问题？

请求数据也都是先根据 isPending 再根据 data 来读取的，想不明白怎么还能这样；本来我以为是 better-auth 的 isPending 有问题，查了一下，确实之前有这个 bug ，但是五月份已经修复并 merged 了；也试了一下不根据 isPending 也是有问题。

也像我说的一样，如果用 useMounted() 来提前区分一次，这样也是 100% 不报错的；
所以我觉得是 Next.js 在预渲染的时候出问题了？毕竟就算是客户端组件也会预渲染。

@heishu 用 middleware 的话也是，所有页面失去 SSG ，和 HydrationBoundary 是一样的

这 VSCode 最近更新的都是啥啊，这两天 ESLint 的扩展也是，更新后直接挂了不能用，一堆 Issue ，降级后发现上个版本还是 2023 年的笑死

估计是爬虫，我去年就遇到了，47.128.xx.xx 的 IP 段一个劲抓取我博客页面，后来遇到阿里云的，UCloud 的，每次我都去手动屏蔽，然后去填单子举报。
上 CF 会影响国内访问的体验，非必要还是不太推荐的。

用智能家居，不是得买个带蓝牙网关的最好嘛，不然家里那些温度计、灯泡之类的，都是要用蓝牙，你还得再买个蓝牙网关，岂不是有点麻烦……

然后 Home Assistant 也是占内存的，配置上最好 512MB 内存

选路由器推荐上这个网站（猫点饭），能看详细配置，不是广告： https://mao.fan/select

我之前在 OpenRouter 里充了 5 美元，然后自己部署了 NextChat 对话前端，没做加密，结果充的钱被人盗刷完了；估计有些 AI 中转也是这样的，利用爬虫扫描全网的没加密的 AI 前端，然后接上去，白嫖别人的 AI ，没有成本。

我倒是觉得有恐惧感也是很正常和很合理的，主要是插件这个东西完全看厂商脸色，没事改一改 API 都够你受的，当时 manifest v3 挂掉那么多插件，谁知道以后又出个 v4 挂掉多少插件。

做小工具之类的，或者不想深入了解的，建议直接做油猴插件，这个分发也简单不用去谷歌市场注册填一堆信息；非得做插件的话，还是建议用前面几楼提到的 WXT ，这玩意从 i18n 到 react/vue 集成，甚至 vite 打包都帮你考虑好了。