为啥要用 hook 发请求呢？像 useSWR 看起来很优雅，一方面 post 请求不适合 useSWR ，另一方面因为是自定义 hook ，请求的返回值必须在组件内使用。而且 useSWR 自身也是知道声明式的局限性，还是提供了命令式的执行方式。绕了一圈又回去了。。

比如说有一个用户点击后可以刷新数据的场景，useSWR 请求的参数（查询的参数和分页的信息）没变，但是对应的数据可能在后端已经更新了。useSWR 就显得很僵硬，只能依赖另一个手动指定的变量来触发更新。

就像楼上说的，直接搞一个状态管理，在 action 里面发请求，修改 store ，然后组件通过状态管理提供的 hook 就拿到 store ，比如 redux 的 useSelector 之类的。

最后夹带一点私货。 推荐一个状态管理库 https://github.com/bytedance/react-model 真的好用

@wonderblank 对的，起码自己可以控制什么时候该 redner

@CookCoder 挺好的，每年更新一次，明年的留个 pr 机会给我（手动滑稽）

自己本地也试过一些 benchmark ，确实绷不住，原生的太快了。

交流群二维码失效进不去了，能再拉一下不，有些问题想讨论讨论

看了一下回答，误解题主的意思的人很多。总结一下认为 1 楼的说法是比较正确的，举个例子：

2 个字节的 utf-8 中
110X XXXX 10XX XXXX 理论可以承载字符 2^11 ，2048 个字符
但根据标准，实际分配给这个段的 unicode 码点范围是 0x81 - 0x7ff ，也就是说只有 1920 个字符，
二进制表示 unicode 码点：0000 1000 0001 - 0111 1111 1111 ，把后 11 位分配到 110X XXXX 10XX XXXX 上，直接位运算是最方便的。
unicode （ 0000 1000 0001 ）=> utf-8( 110|<0 0010>| 10|<00 0001|>) 肯定比
unicode （ 0000 1000 0001 ）=> utf-8 不浪费版( 1100 0000 1000 0000) 运算方便

utf-8 空间完全够用，不像 utf-16 ，空间极限就是 0x10ffff ，综合来看应该是这个原因吧

感觉这种风险无法衡量，因为不清楚这个开户，会把你的资料同步到谁那，会和什么挂钩。比如开通花呗，就有可能和征信挂钩，这还是抛开隐私问题不谈的情况下

i+=1 多写一个字符不会死的。。

可以的，学习了

学做菜，或者美食

@CNN 哪个 app ，是能说的那种吗？来个 base64

你走的早，没碰上 lynx

这种肯定是走 ast 能力了，不过感觉有点高射炮打蚊子。。

可以吊打 3090

没见过 pc 适配 safe area 的，纯粹是恶心人

@fjc0k 这个思路可以有，感谢分享

@SmiteChow 感谢分享，拓展了视野

已用 native 实现 ，此贴完结

@5200 户外使用，除非安卓端能起一个 nginx 或者类似 nginx 的本地代理转发。如果有这样的软件，辛苦分享一下

@eason1874 统一回复一下，后端服务不是自己的，抓的 api