@Andim 谷歌右侧推荐的这个有时候会抓错，内容也不一定准确，只能当参考

看看能给多少钱，给超过 20000 刀的话也许能收几个 0day

fcm 留后台的本意是让你加密发数据，唤醒客户端后解密再显示，这样谷歌也不能知道你给用户推送了什么内容

网络请求建议直接上 swr 吧，你这个看起来是想做类似分页/无限加载+刷新的效果？那么 swr/infinite 里就可以做了，直接 setcount 然后再 revalidate ，不会有任何冲突，也能实现想要的效果。。。

cf 那个 browser rendering api 要用爽只能用 durable object(否则每月只能开 100 次会话)，那个就得 paid ，然后你一旦 paid ，每次 0.1 刀完全没法好好用（）
只是为了提取内容的话不如直接用隔壁现成的 jina 的 api

第一人称射击游戏：指艹猫吗(划掉

next 搞这么复杂的一个原因就是
现代网站很少是单纯工具页面或者完全可以服务端预先生成的
即使是 figma 工具类的，起码你也可以先 ssr 生成一个框架，让 logo 或者 loading 一类的元素先一步显示出来（当然你也可以手动先搓一个 loading 的 html ，但这需要同时维护两个东西，就麻烦一些了
完全可以服务端预先生成的页面就不用说了，但更常见的情况是，一部分可以预先生成，一部分不是，比如博客和评论区（当然你可以说评论区可以不用 js ，这个不讨论）这里假设是需要 js 的评论区。。。

pages/worker
还有 workers ai <- 不过这个现在要付费了，但是 beta 版的模型还是免费使用

现在动画包括一部分厕纸改编在内，有些也会精心塑造反面形象，比如《憧憬成为魔法少女》（划掉，虽然其实传统意义上的魔法少女动画，也通常不会完全正义邪恶一边倒，除了完全面向低龄儿童的类型）
还有近年比较热门的转生恶役（如《转生成为了只有乙女游戏破灭 Flag 的邪恶大小姐》）系列，虽然某种意义上是让原始设定里的邪恶方变成正义方的反转设定，但另一个角度其中也描写了邪恶大小姐之所以成为邪恶大小姐的原因，放到“原始设定”里也会觉得合理的那种，从原本的“恶人本恶”变成了制度和历史经历共同塑造的反面行为

最近我发现把 bot 丢 cloudflare worker 上跑是一个好主意😜（前提是你会写 js/ts ）
尤其是考虑到免费+免维护这一点（不过我自己是用了 worker paid 套餐了）
不过架构方面和单体程序有点差异，单纯作为一个建议吧
日程提醒可以用 scheduled 来做，每分钟检查一次即可
tg 请求响应的话用 grammy 的 webhook
数据库，用 D1
另外一个思路:TG 目前开放了小程序的接口（实际就单纯网页套壳，但提供了无缝用户认证的能力），可以用 cloudflare page 搭建一个网页管理界面，后端对接到 worker 上（推荐用内置的 worker ），这样在 tg 对话式 ui 不够好用的时候可以用 web 来补充

都有 ptrace 特权了你还想怎么保护啊。。。你设置的所有限制都还是可以被绕过的呀，攻击者总是可以通过修改内核的方式来破坏你的保护
真的要做的话应该走可信计算的思路做

所以为啥要手动关闭，这玩意不是这么用的吧

android 现在要做的话，只有输入法可以后台读取剪切板了

这不都是你自己管理的东西吗，csp 防止的是未授权的修改，不是防止你在你自己域名上的授权修改

@Autonomous 替换了也没法解密用系统加密 api 加密的那部分，比如浏览器的 cookie ，保存的密码这些（）这些只有用户正常登录了才可以被解密

@iOCZS 你这个理解上有一些问题，首先不管 class 组件还是 function 组件，都需要重复执行 render ，react 的核心算法就是根据生成的 vdom 去 diff ，这个是无法避免的。
只不过，传统 class 组件有提供简便的（但实际上很容易误用的）方法去直接跳过更新，这个能力在函数组件里是否存在呢，也是有的，就是那个 memo 函数，当然由于 hook 的存在，不能像函数组件那样屏蔽来自 hook 的更新，但这也导致写出有问题的代码更为困难了

确实是不再推荐了，因为和并行渲染这些新的机制有冲突

@StruggleYang 经过测试，14.4.1 已经修复了这个错误，不是给 java 开后门，整个错误都修了

实践中，编译器会给你生成一个 double checking lock