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

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

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

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

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

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

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

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

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

真要解决的话，用这个
https://www.sqlite.org/pragma.html#pragma_user_version
记录一个版本进去，写好升降级逻辑

@xubingok useMemo 是给计算需要一定成本的用的，简单加减乘除甚至字符串连接都不需要。
我觉得你这个例子里用 setState 没有问题，但是扩展到更大项目里，如果每个子元素的更新都要触发 root 组件的更新的话，就有点问题了，这时候可以考虑引入第三方状态管理库来处理
冷知识好多第三方状态管理库也都是接入到 react 的 useState （或者更高级的 useSyncExternalStore ）来处理，但是针对复杂嵌套状态做了优化，避免了“牵一发动全身”的问题，只会在用到状态的地方触发 setState （或者 sync external store 里的回调）

虽然 office 365 那边肯定是有简单的解决方案的（你就存 sharepoint 上，点开可以调用本地 office 套件）

所以要在后端验证啊，你前端验证只是保证用户体验用的

没准可以用浏览器上的 adb （安卓手机可以给另一个安卓手机刷机）
https://github.com/yume-chan/ya-webadb/

不嫌麻烦的话走 websocket 吧，至少难度上可以给攻击者加一些，能干掉不少低级爬虫框架

@jimmy3780 但不管它是由几个字符组成的，表现上还是一个字符，就应该渲染成单个字符

你注入样式的方法不对吧，建议将样式注入到 shadowdom 里，而不是插入全局样式，就基本上不会影响页面了 https://developer.mozilla.org/zh-CN/docs/Web/API/Web_components/Using_shadow_DOM

@lesismal 不过 c++内存模型（和 rust 等一些“现代语言”）的巧妙之处就在于，它把硬件的内存模型和编译的优化模型都统一的结合在一起了，只要保证最终目标（执行结果和内存模型预测的一致），就可以完全无视代码本身的执行逻辑，编写顺序
然后一旦加入了屏障，就同时修改编译的优化逻辑，以及加入硬件相关的屏障代码