F12 的话，用$('input[type="checkbox"]').forEach(item => item.click())也可以（不依赖 jq ，devtools 提供的简写）
推荐用 click ，写着简单，而且有些**框架可能只绑定 onclick

哦，已经有了，当我没说）

是不是可以把 i （ miniplayer ）配制成 pip 模式

@amiwrong123 前面说的被调度走指的不是说内存映射也炸了
而是说 dma 硬件处理上可能会有不低概率观察到只进行到一半的修改（
后面补充的 o sync 就是为了应对你说的这个的 dev mem 的问题，正经解决方法就是用 udmabuf 那个模块去映射，效率也高一点

udmabuf 能 O_SYNC 的原因是加了这个参数后，就会在内核里用 dma_sync_single_for_cpu 来同步 cpu 缓存（
其他普通的实现可不一定有这个）

哦，不对，编译器优化用 asm volatile("" ::: "memory");隔开就够了，O_SYNC 配合合适的用户态 dma 映射实现，应该就足够了
（不过用户态 dma 你还是得考虑调度的问题，没准你循环写入的时候进程被调度走了呢）

虽然理论上这种情况还有编译器优化的问题，也就是如果 a b a 这样写，可能会跳过中间的 b
再用前面说的 volatile 转换方式也不迟（

@amiwrong123 参考这个 https://github.com/ikwzm/udmabuf mmap 的时候加一个 O_SYNC

@geelaw 我感觉根本不是一个目的啊，drop_caches drop 的是 page cache 这些，和 cpu 缓存一点关系都没，下文提及的也看出不太像是访问文件的问题）

不过 linux 用内核用是有正当理由的，你这是 x86 带有硬件 dma 或者别的硬件内存映射技术一类的吗，那样用户态也访问不到吧

@amiwrong123 （小寄巧：用 *(volatile int __attribute__((force)) *)&x = 1 写入
内核也在用，不过把 __attribute__((force)) 加了个宏__force 简化）

我觉得这里有很多概念上的问题啊。。。
/proc/sys/vm/drop_caches 这个显然和 cpu cache 没有关系
你要 bypass cpu cache 的话，直接 volatile 不就好了

@debuggerx 但还有一个是 scintilla 编辑控件，这个也是被直接用了（
感觉就像是进口发动机（

但核心文本编辑器控件是 scintilla （
其实我比较好奇到底啥程度才算自研，为啥 vscode 改就不能算，但用 qt 就可以算

@binfreeze
很显然和所有工程一样，软件工程也是妥协的艺术，理想主义不能当饭吃，现实中就是会有多种相互冲突的需求，尤其是不同类型的项目，需求差异更是千差万别，代码设计的再好，用户也无法察觉，只能从主观上去评估，谁会在意点下按钮，需要用几个指令周期，访问几次内存，发送几个请求才能完成呢？
说到底，最主要的问题就是，约束太多，而资源有限。就像现代无法复刻 2000 多年不倒的古罗马混凝土建筑一样，并不是现代人没能力做，而是不想分配几十万“人月”的资源去做，现代建筑设计寿命就几十年，你造 2000 年不坏的建筑有什么用呢
就像混凝土的评价指标不止是持续时间一样，代码的评价指标也不止是性能，开发成本你当然也得算进去，还有更多的指标和具体目标相关，例如互联网领域你期待能快速变更以适配风口，2C 领域你期待能实现美观的界面，2B 领域你期待数据安全保障，工业领域你期待能持续维护
当然不是所有的指标都互相冲突（比如你确实可以做得既优雅又漂亮，还有很高的性能，在主流平台都能流畅运行，还容易扩展，方便后期维护），但显然几乎所有其他指标都和开发成本/时间冲突，在成本固定，时间有限的情况下，某个方向追求越高，分配给其他方向的预算自然就更少

vscode 我记得已经内置了 profile 功能，还能在不同 profile 中可选的共享一些配置）

@MakinoharaShoko react18 有专门的 useSyncExternalStore

我建议用第三方前端解决这个问题