@est 然后发现不同平台有不同的本地库依赖：比如常见的那些机器学习项目，直接复制的话几乎肯定会炸（ win->linux)

你这文字弄起来也太难阅读了吧。。。
中文窄，英文宽，这能读？？

虽然我觉得大概率是写错了（）

说白了就是早起项目设计的问题，一开始没做好依赖隔离的机制（全局安装包），只能后期不断打补丁解决。。。

可以用 experimental 里的 unstable_Activity

我建议要发异步请求什么的，用 swr 这类库去处理吧，之后 ssr 和服务端组件都可以用上

你这全用字符串标识，最后管理起来有你麻烦的（）
这看着还是传统 vb 的全局思路，承认吧，这玩意根本没有可扩展性。。。（而且你这么一搞性能也没了）

@bthulu esm 时代不需要手动拆这么细了，只需要按实际目的拆即可

但说实话这得怪微软（
它们也知道复制小文件慢所以才搞 dev drive

有没有一种可能和 Fiber Reconcilier 的调度有关系

要不你试试不同版本的区别（我感觉这应该有差异

除了 react 有意将副作用隔离之外还有一个就是语言限制，即你不能修改一个被解构出来的变量（虽然就算你不解构它也不会变）

@whathappen 确实，但是你可以让通知内容对 apple 保密，只能由应用指定的 extension 来处理，让 apple 服务器只可以知道有这么一个通知的存在，大概有多大，仅此而已

你不考虑下是不是硬盘坏了吗

有一个问题是隐私相关的：不唤醒就直接推送内容的模式下，推送方案提供方将会获得推送内容的全部访问权限，在一些隐私高度敏感的应用里是不切实际的。
我觉得还是果子的方案好，允许应用专门注册一个扩展，那个扩展只能用来处理推送信息，信息是单向流通，即 app 可以将解密密钥传递给扩展，扩展无法通过其他方式通知 app （然后就不可以唤醒了）

盲猜底下会有 vim 键位，hjkl 的

我记得 go 某个版本改了循环的语义啊
你再去问是不是有点不对

最近几个版本都有 0day 发现。
最近一个还是严重 rce 的，确定不升级吗，任何小于 120.0.6099.129 的都受到影响
@yyzh 不幸的是，这些 flags 最终都会被删除，没意外的话三个版本就没了