100 次，印度接近 20 次，中国 7 次，美国 1 次，难顶，大概率还是在亚洲和非洲混

不加，从不主动加微信

zerotier 的确不是很稳定，和江苏南京的教育网互联，会突然降到 0 ，重试了 33 次。
https://i.imgur.com/QC1KQUV.png

不知道你 Zerotier 速度有多少？我这边试了速度还可以，没用 Moon 节点。上海电信，测速如下：
https://i.imgur.com/daa0uAZ.png

你甚至可以把你的状态保存到 window 对象来存入，还有很多别的方式莱实现状态共享。为什么要有专门做状态管理的库呢？

放弃使用触摸板了。之前姿势不正确，手老是抵前和触摸板平行，然后手就麻了。一用触控板手就麻，成职业病了。姿势一定要把握好

@eggt 开启 window.commandCenter ，Mac OS 需要关闭 window.nativeTabs ，Title Bar Style 设置为 custom

@Trello 感觉有点引流，可以去看一下卡颂的 React 技术揭秘： https://react.iamkasong.com/

你可以尝试一下关闭 Automatic batching ，再验证一下那篇博文的正确性。我看了一下，不知道为啥生造了这么多名词，看着真累。只说其然，而不说所以然，真想了解细节建议看源码。

你用的是 react 18 来验证的，react 18 版本的 setState 是 Automatic batching ，你可以去看一下这个新特性。他那篇文章是 20 年的，有些系列不适用 18 版本的

@zhangleshiye 不知道你哪里感觉不一样。不过有不同的体会很正常，我的很多体会都是做需求思考得来的。就举个简单的例子：一个列表页，进到页面默认请求第一页的数据(得用 useEffect)，可以切换页码请求新的数据。有筛选项，修改筛选项后，此时页码要重置到 1 再请求数据，如果页码和筛选项不是维护到一个 useState 的话，就会很麻烦。为了调用请求函数的时候拿到重置后的页码值，这时候你就本能地想到得用 useEffect 来处理，筛选项和页码变了再调用请求函数，这时候你会发现请求了两次。这个简单的例子，我觉得很多人会遇到过，看 Dan 写的两个文档，立马就应该知道要将筛选项传给请求函数，而不是用 useEffect 。随着业务复杂，你可能会发现 react hook 其实不怎么好用，这也是为什么有一些人很排斥。感觉你之前应该没怎么写过 hook ，你现在看那些文档，我觉得很难有体会，很正常，多踩坑多思考。

推荐看一下 Dan 写的文章： https://beta.reactjs.org/learn/synchronizing-with-effects 和 https://beta.reactjs.org/learn/you-might-not-need-an-effect 。
1 、这里的正常操作是：事件调用后，计算最新的筛选项（包括页码和其他的筛选项目），筛选项可以用 state 存起来，把筛选项作为参数传给请求函数进行调用。
2 、不要滥用 useEffect ，useEffect 会让你很容易会有响应式思想，页码变了，setState 更新页码，然后 useEffect(() =>{ 请求函数 }, [pagination])，这样子会让代码很难维护和问题跟踪。只要是事件触发的操作都尽量避免使用 useEffect 。
3 、数据请求的话，推荐用 SWR 或者 react-query ，你自己封装也可以，不建议在代码中直接用 useEffect 来写。用请求库能让你的工作事半功倍，这也是 Dan 推荐的（ Keep in mind that modern frameworks provide more efficient built-in data fetching mechanisms than writing Effects directly in your components.）
useEffect 我个人觉得不是一个很好的 Api ，对使用者的心智负担很大，Dan 的两篇文章里面不推荐的用法我基本都写过。官方最近考虑新增一个 API： https://github.com/reactjs/rfcs/blob/useevent/text/0000-useevent.md 。

@qingfeng9527 慌的原因是什么？有房贷、车贷？有小孩要出钱？大环境如此，每个人都有被裁的可能性，个人觉得坦然面对，积极准备是最好的选项，单纯的慌并没有什么作用。