这种操作也不是一天两天了，好早以前就有在登录屏幕通过输入法打开别的东西的方法。。。

得用上模块系统才可以使用跳转。。。

我记得以前微软拼音在代码里写死了这个逻辑的来着，还被人喷了

我记得是可以配置开机后自动执行脚本的啊

dex 不需要 x 权限（

多半是白嫖某些大厂的 cdn ，参见之前的 freecdn 项目（我不是说这是道德的）

用不用不是得看正确性吗，当然除了传统意义上的分布式锁之外也有别的方案，比如乐观并发控制

哦写反了，反过来就对了

这也不是分组吧，就两个排序而已，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 没法背锅）

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