@v2byy 这个链接感觉就是他的显卡有问题，如果是驱动问题的话不太可能只有个例。

建议重装系统

感觉这就是个例、中奖了，内存或者 CPU 有问题导致的。网上查到几年前的问题大概率不是同一个问题。

@westoy
我在用联想小新 15 4800U 那款，USB 挺正常的，没什么问题。而且 Intel 啥时候便宜过了？这机子 4300 元买的，换成 Intel 能有这么便宜？

@autoxbc
硬件解码是 GPU 提供的，这个锅应该属于 Intel 。
感觉上 Intel 核显驱动问题是最多的，很早就传出会导致 dwm 内存泄漏，但是因为大多数用户不会用核显跑游戏，且出问题时一般都是在微软的程序中出现(比如 dwm 内存泄漏，或者蓝屏时出错的驱动是 DirectX)，很多人都去怪微软了。
感觉在 Linux 上 Intel 核显的问题也挺多的，比如我最近就遇到一台 i7-6700 的机子核显无法驱动，一台 i9-10900 的机子装 Ubuntu 22.04 后时不时会黑一下屏，马上又会恢复。

@CloudnuY 二手主板是正常的，大多数厂商换主板都是把原来坏的主板返厂，然后厂家给一个好的主板给售后点更换，这个好的主板可能是全新的，也可能是之前坏掉的主板返厂修好的。
至于换错主板以及留指纹这就是售后点的问题了。

调试看看是什么问题，然后自己写 polyfill 解决。
要别人帮你调试的话请发源文件。

软件不支持动态 DPI 吧？截个图看看？

@wangweitung #9 可以在手机 app 上用银联卡购汇，然后转账到 Visa 卡上

个人比较讨厌.NET ，准确说是讨厌.NET 上的 GUI 框架，因为个人认为.NET 的 GUI 框架破坏了 Windows GUI 的开发体验。
早年的操作系统基本是只提供一套很基础的 API ，比如 Unix ，Win32 虽然有提供 GUI 相关的，但也是比较简陋的。而进入二十一世纪以来，许多操作系统都开始提供更丰富的 API ，比如 macOS 的 Cocoa ，让开发者通过系统内置的 API 就能开发出美观、完善的应用。
但是微软在推出 Windows Vista 时并没有加入现代化的 API ，而是同时推出了基于.NET 的 WPF 。如果.NET 做得好那问题也不大，但是长期以来.NET 不能直接使用 Win32 API ，需要自己手写声明。不同版本的 Windows 系统中.NET 版本不一致，要兼容多个系统版本，要不然给旧系统安装新版本.NET ，要不然只能用旧版本.NET 来写程序，没法用新特性。再者，WPF 默认主题直到现在都没有和 Win32 的主题统一，Win8 、Win10 、Win11 更新主题后，WPF 那个都显得很难看。
为什么微软要这么搞？我认为，把 WPF 跟.NET 捆绑，是为了拉拢开发者去用.NET ，“你想要爽的开发体验，那就别用 Win32 了，来用.NET 吧”。同时当年因为微软对生态的把控力度不强，Windows 上有很多别的语言 /编译器 /框架，给 Windows 本身加上一套丰富的 API ，很可能被竞争对手拿去发扬光大，所以不内置到系统中，而是独立出来。Windows 内部有一套微软私有的 GUI 框架，资源管理器、任务管理器等许多系统应用都有使用，就是不开放出来。
另一方面，.NET 没法轻松地调用系统 API ，WPF 不使用系统主题，大概是为了跨平台考虑。这么做有好处，可以避免.NET 跟 Windows 捆得太死，比如 Swift 最初推出时基本是 macOS/iOS 专用语言，加上 macOS/iOS 的 API 很丰富，于是很多库就依赖系统 API ，后面 Swift 能跨平台了很难移植。但是很多.NET 用户只是想快速开发一个 Windows only 的应用，想使用一些比较底层、高级的系统 API ，想要有接近原生的 UI 风格，.NET 用起来就很麻烦。这就好比苹果发布 Swift ，写 GUI 只能用 SwiftUI ，不能使用以前 xib 那套，界面风格还和系统不一致，要调用 objc API 要自己声明一遍。
现在新的 WinUI 稍有起色，微软又试图用 MAUI 来分裂了。我认为如果 MAUI 搞起来了，势必会有一堆基于 MAUI 而不是 WinUI 的控件、主题等出现，久而久之就没人给 WinUI 写代码了，都去写 MAUI 的代码了，结果又是跟.NET 捆死。有的人可能会说，那微软自己搞的 React Native for Windows 不也类似吗？确实是这样，但是 React Native 是可以嵌入使用的，可以在现有的 C++或者 C#项目中嵌入一个 React Native 写的基于 WinUI 的界面，而 MAUI 据我所知没有这样的功能，即使要嵌入，.NET 运行时体积也十分庞大。而且 React Native 是用 js 写的，一些底层高性能的操作还是要依赖 C++，没有完全抢走生态的风险，如果换成 MAUI ，可能底层代码也用.NET 写了。

好奇那个美式插头是长啥样的，能发个图看看吗？

Info.plist?

如果机子没有 root ，想以 shell 身份执行的话，可以看看 Shizuku https://shizuku.rikka.app/zh-hans/

有 root 的情况下直接执行"su -c <命令>"就可以了，会提示授权的，你可以下载一个终端 app 执行一下看看效果

@singerll 华凌的空调没有阉割红外接收器，可以自己买遥控器，不配遥控器的同时还加上了蓝牙模块，有的时候 WiFi 信号不好或者不想连 WiFi 也能遥控。反而美的的空调配了遥控器，就把蓝牙模块阉割掉了，没有就没有了，也没办法自己加装。

如果不稳定的话，为啥 Java 还要搞 JNI ？弄个不稳定的东西来坑人？如果是有 bug ，为啥 Java 不修复，留着 bug 来坑人？

“高速 2.0U 盘”，USB3.0 刚出那段时间就很多把主控换成 3.0 ，仍然用较差颗粒，但是卖得很贵的 U 盘。

@Buges 配合专用工具的情况下，注册表也是人类可读、用户友好、冗余字符少。至于纯文本是否影响性能，HTTP/2 相比 HTTP/1 就改为了非纯文本。以及数据不一定就只有“那点”，久而久之会越来越多的。

@Buges 性能方面我没测试过，说不清楚。
选择二进制格式，我认为苹果是做过调查，比解析纯文本更快的。以及改用二进制格式不就是“换个更简洁的格式”吗？还是说你认为只有纯文本才算简洁？

@Buges
“没有任何好处”
有数据库带来的完整性保证，以及缓存的性能提升。

“纯文本配置文件简单直接够用”
那为什么 macOS 要抛弃纯文本 XML 的 plist ，改用 binary plist 呢？

@Buges 注册表本质是把各种配置文件中每一项给拆成了文件系统树的结构，如果其他操作系统算上配置文件中的每一项，还很容易知道是干什么的、属于哪个程序的吗？
Linux 因为是开源的，翻遍代码是可以知道是干什么的，但是并不能说容易。macOS 因为不开源，即使没有注册表，也一样很难知道是干什么的、属于哪个程序的。
这不是注册表本身的问题，而是不开源+系统复杂的问题，注册表只是把问题放大了，配置文件则把问题缩小了。
GNU/Linux 因为遵循 Unix 哲学，整个系统都比较简单，清理起垃圾确实不复杂，这点我不否认。但是遇到 Android 等不那么遵循 Unix 哲学的系统，则没那么简单了。