哦写反了，反过来就对了

这也不是分组吧，就两个排序而已，order by index, group

@onlyfor 给客户的话直接源码打包发过去就可以了，不必专门上 github 的。。。到时候开源出了问题客户可能还得找你麻烦

chrome 可以用 Virtual Keyboard API 来获取软键盘尺寸（移动端专属）
其他的很麻烦，可以参考下 https://interop-2022-viewport.netlify.app/combined/icb-fixed-visual/

(其实浏览器也不会绘制超过屏幕的内容（ edge 有几个版本你就会在滚动过快的时候看到白屏被一个个方块填上的过程），但超过屏幕的内容不止是绘制的问题，还有布局等其他因素需要计算，加上为了 js 访问方便而设计的对象接口的 overhead 才会显得不能装太多东西，实际上就单纯说显示一个巨大的表格来说浏览器问题不是很大，好多设计起来就只有单页的文档（例如隔壁的 rust 的某文档，html5 的单页 spec ），其内容长度远超一般“无限滚动”正常用户能滚动到的范围，也可以顺利的在浏览器上呈现。。。（当然和一般无限滚动场景不同的是，它内容上是较为简单的，计算布局的压力也会小很多）
桌面端除了用虚拟滚动的思路之外，还有一种叫 imgui 的思路，其抛弃了控件的抽象，根据滚动位置直接计算出需要展示的范围，然后每次都只画用到的部分，也可以解决这个问题==（有一些商业表格控件就是这个思路）
之所以虚拟滚动一类的机制需要使用“复用”，其本质不是绘制元素有多慢，而是为了表达这个 UI 对象抽象带来的额外成本很高，不能简单的丢弃再重建，或者干脆建立一大堆放着

所以是什么协议发送的呢，怎么发的，又是怎么接收的

两件事，一件是微软 azure 炸了，另一件是 crowdstrike 炸了
导致上云和下云都有风险（）

https://www.v2ex.com/t/1058556#reply2
联动隔壁

是不是开了第三方 cookie 屏蔽，youtube 需要访问 google.com 域名下的 cookie

@lookStupiToForce 最后发现 ai 理解出现了亿点偏差，然后大家全搞错了，最后还得回到人工检查上来（因为 ai 没法背锅）

硬生生的把看文档就能解决的事情，转变成实验科学。。。

（新建一个港区付款资料用港区的支付吧（可以用银联卡）

@Patrick1 有啊，你看看你现在是不是加了 5 个铜币

@wuhao1 就是一周前还用过，没更新的版本，我刚更新到最新版也能看。。。

https://imgur.com/a/b42jd66.jpg 我这测试了一下 yt-dlp 还是能下载 4k 的，除了有一些警告之外
@loveinj
刚测试了 smarttube （旧版）也是能看 4k ，毫无问题，可能是账号限制？

@UncleCAT4 https://github.com/codehz/tganime <- 哦忘记发了

@UncleCAT4 单纯按订阅渠道推送到 tg 群的不同 topic 而已，主要是给我一键离线下载用（（至于为啥不直接下载，首先 worker 就不行，其次还想给大家一起用）

我一个用来跑 rss 订阅推送，中值 CPU 时间 45.7ms ，仅用了 D1 服务（
虽然理论上跑 vps 上也一样，但 worker 跑起来不需要维护（
另一个是 cloudflare pages ，用来跑 telegram bot ，同时集成了 webhook 模式和 mini app 的网页，还使用 queue 来实现定时任务（因为 worker/pages 本身不能长时间执行）
serverless 这玩意主要得顺着思路用，不能用传统的程序逻辑来写