判断 Accept 头里的 text/html 是不是排在前面的位置就可以了
img 元素的话 text/html 一定不会出现

Webview 原则上可以拦截 http/https 访问，不上架的话用私 api 有就可以，当然剩下的部分非你自己实现，拦截这个的好多知识为了绕 cors 一类的，不是拿来搞代理的

我还以为能求解丢番图方程（）

@koast 因为并没有使用你的摄像头吧（）

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

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

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

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

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 对象抽象带来的额外成本很高，不能简单的丢弃再重建，或者干脆建立一大堆放着