@nullboy 没用过 alist ，但以前用过一个 Golang 写的 webdav 服务端，本地用 IDM 多线程下载，速度会越来越慢，然后发现 webdav 进程 CPU 占用极高，停止下载后也不会降低，且后续请求完全没响应，于是就改成用 nginx 了，并没有出现上述问题，也不想再花时间测试各类 webdav 服务端了。

看上去没问题，不支持拷贝的对象在 vector 中也可以构造时一次性初始化。

@murmur 说反了吧？ 5V 不需要诱骗，买个普通的 USB 电源适配器就是 5V 。12V 可以诱骗，没记错的话 PD 有 12V 档位。

@villivateur 诱骗是针对路由器等不支持 PD 的设备，在设备和支持 PD 的电源适配器之间加个诱骗芯片，芯片会告诉适配器想要什么电压，然后把这个电压输出给不支持 PD 的设备。

不一定可行，电池充电器输出的电压不是恒压，其中是有一定算法控制的，可能还有过充保护之类的，长时间通电会自动断电。电源适配器输出的是恒压。

Beyond Compare 有 macOS 版

@amiwrong123 是的，另外 MIUI 优化也是一直开着的

我选 Root ，没问题

不维护了吧，避免用户下载后遇到问题找他们麻烦

之前听说 Windows Hyper-V 有“MAC 地址虚拟化”的功能，就是虚拟机和主机可以用相同的 MAC 地址，曾经有传言称这种模式下，虚拟机里跑锐捷认证客户端，主机也能上网，可以考虑一下用此类方案。

可以参考这里面的配置试试 https://her01n.com/2021/05/13/webdav-server-with-nginx/
其中的 if rewrite 可能有改进空间，不过访问量不大的话不改也不怎么影响性能

@lingeo DP 的逻辑是显示器关闭后会认为断开连接，尝试都用 HDMI ？如果没有更多 HDMI 的话，尝试对调两个显示器？

杜比视界有很多种模式，最佳的是解码设备和显示设备都支持，解码设备会把杜比视界的元数据发送给显示设备，显示设备会根据这些数据进行调整，获得更好的效果。
如果显示设备不支持杜比视界，解码设备会解码成普通的 HDR 或 SDR 来显示。

@ysc3839 更正，后面一段应该是“至于文件关联、右键菜单以及 shell 扩展等功能，Windows 和 Linux 都免不了要往特定位置“注册”关联信息”

副屏是 DP 连接的吗？

@lisxour 然而注册表和文件系统类似，在其他操作系统中，如果某个软件要往文件系统某个地方写东西后才能使用，那重装了系统后也不能正常运行。
Windows 曾经有 DLL Hell ，传统 Unix 一直有 so hell ，但 macOS 却很少听说有 dylib hell ，问题的根源是系统级的共享库。Windows 虽然建议程序自带依赖，但仍然存在 COM 这个跟注册表关系密切、系统级共享的功能。虽然 COM dll 是可以免注册直接使用的，但哪有直接注册了就用简单，于是开发者都喜欢往系统里注册 COM 组件，重装系统后注册丢失，自然就用不了。
至于文件关联、右键菜单以及 shell 扩展等功能，Windows 和 macOS 都免不了要往特定位置“注册”关联信息，这方面 macOS 做得较好，文件关联信息是跟随 .app 捆绑包的，不需要单独注册，不过一些复杂的扩展还是需要注册或者安装到指定位置的。

大概可以用 acc ，但是要 root
https://github.com/VR-25/acc