@wnpllrzodiac 64g 也能干爆，我 32g 挺不过 1 分钟

@kk2syc 应该不是，在其它页面也有这个问题

@kk2syc 没太懂和 WASM 有啥关系

应该是有个接口一直调用：

两年也算正常吧，自己换个微动就好了，建议买之前看看微动寿命。我现在微动热插拔的，懒得焊，楼主觉得麻烦可以试试这种

跟楼主说吧，就算祝福没写在红包里，估计也要说一句，这种属于立体防御，正反自己都有理。而且婆婆都转帐 5200 了，心意这么足，就因为一句话，楼主老婆就受不了了？这是什么心态？

@Plumbiu 像是这种，模拟了一下 ```jsx

import { useEffect, useRef, useState } from 'react'

function useSWR(url: string) {
useEffect(() => {
console.log(url)
}, [url])
}

function App() {
const sceneRef = useRef<number>(0)
const [count, setCount] = useState(0)
useSWR(`/?scene=${sceneRef.current}`)

return (
<>
<div>{count}</div>
<button
OnClick={() => {
setCount(count + 1)
sceneRef.current = count
}}
>
count+
</button>
</>
)
}

export default App

```

@vace 我很好奇这种库和第一种差别，除了封装好更简洁，还有其他好处吗，因为我第一眼觉得 useSWR 参数变了，不还是要重新请求，假如我有个参数 scene ，只有后端区分场景，前端 ui 不可见，使用 uesRef 保存，state 更新岂不会发起二次请求

@realkaiway 用了下班更晚了哈哈哈，这要多久才能改造完

react 的 useEffect 是最令人头疼的，很多新手写很多 useEffect 导致后续项目维护机器麻烦

@jayasme https://www.techempower.com/benchmarks/#section=data-r23&test=json ，可以看一下 next.js api 性能，排倒数第四，不是一般的差

@rocmax 其实我想说的是 React 的水和包括还原组件树，hydrateRoot 方法就能看出来，需要接受用户的根组件 https://react.dev/reference/react-dom/client/hydrateRoot#hydrating-server-rendered-html

@rocmax 我觉得你把水和的概念缩小了，水和就是包括还原组件树

@rocmax RSC 就是会水和整个页面，至少水和的数据都是包括静态部分的，见 https://github.com/vercel/next.js/discussions/42170 。更明显的例子就是我博客实际 HTML 内容只有不到 4k 个字符，水和数据有 1 百万个字符

@twig 啥时候莫名其妙会变成客户端渲染，默认不都是服务端渲染嘛

跟楼主说一下，楼主的例子其实现实中也有类似的，例如轮询，对象的毕设用的 lvgl ，里面的回调事件就是 30ms 轮询监听的，另外我之前也写过监听窗口句柄变化的时尚小垃圾，也是过 1s 左右轮询一次。楼上觉得没实际意义大概率是见识太少了

@lscho es6 哪来的 async 和 await

之前在这个部门，有点累