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

我朋友坐标上海，也在咸鱼买了一只起司，价格八百，是家养下的崽，品相和你要价 2000 的差不多。你这价格都跟猫舍有得一拼了，出不了很正常，要不降低价格，要不问问熟人要不要。

@Ginruts 推荐这个网站 http://uz.yurixu.com/manage/shanghai.php

@wy315700 现在回国的成本也很高，机票都要大几万

老哥稳，工作电脑都敢升级，要是出问题了，带薪修电脑

更新了一下，同样复现了

退吧，不顾大概率要等到七八月份？

我搜了一下，今年一月底就有新闻说奥园要“暴雷”，标普去年 11 月 16 日对奥园信用评级由 B 调至 CCC ，去年 11 月 26 日，中国奥园突然解散公司旗下全部大区，大批员工离职。这还是去年底买的，这么多负面新闻，买之前没有调研过这家公司的现状吗？这雷踩得不冤。

1.让自己深陷债务危机，需要靠借高利贷来偿还的人不值得同情。
2.明知道朋友是借高利贷，还理所当然接受的，完全是一个不负责任的人，朋友的征信和逾期风险不用管？
3.在他没有还完之前，今年又向你借钱你借不借？大概率还会向你借钱的。
4.我不觉得你们这段友情牢不可破，换作是我，有一个很好的朋友，是断不会让他陷入这种风险之中的，你觉得很有成就感，我觉得很可笑。
5.现在尽量减少损失，借出去的就不要想太多了，好好和女朋友生活，千万不要再借了，你也有自己的生活，这个窟窿已经很难补了，煮好

好看，感谢

@CptDoraemon 推荐一个更优秀的替代品 https://github.com/Schniz/fnm ，nvm 严重拖慢 terminal 启动速度

@Junaaq v2er

刚工作的时候，对测试提的一些不属于自己的 bug 也很反感，也很担心。有些公司会有 bug 指标，bug 多了还会有批评，扣奖金之类的，能理解那个前端的不爽点，但态度很有问题。一般测试是对很多个前端，后端和产品，有些 bug 刚开始的指向不明确，确认之后再转就行了。个人觉得没必要把问题弄得这么僵，需求是大家协作弄好的，遇到不配合的，拉群和他领导直接说问题就好。