@ellipsecheung 你在访达搜索名字是能搜索到的，但是点击会闪退。

Beta 版就这样，本来我是馋 iPhone Mirroring 功能才升级的，升级了之后发现目前还用不了。然后发现 QQ 、BetterDisplay 都闪退，BetterDisplay 还好，作者 Github 紧急升级了个 pre-release 版本，但是 QQ 几个版本都用不了，包括上面提到的 6.9.12 ，打开是能打开，不过全是空白界面。

@xbird 试用过了，感觉 ui 还是非常好看的，不过前端我没啥经验 233 ，我参考下，不过本身扫描过程的实时可视化感觉还是有必要的，要不用户等着太无聊了，看扫描的过程挺解压的。

如果你的服务器上有 python 环境，那么有个非常方便的方案，什么都不用做。
ProcessBuilder processBuilder = new ProcessBuilder("/usr/bin/python3.11", "/path/to/python.py");
try {
Process process = processBuilder.start();
try (BufferedReader reader = new BufferedReader(new InputStreamReader(process.getInputStream()))) {
String line;
while ((line = reader.readLine()) != null) {
// 你的逻辑
}
}
int exitCode = process.waitFor();
System.out.println("Exited with error code : " + exitCode);
} catch (IOException | InterruptedException e) {
System.err.println("An error occurred while executing the process: " + e.getMessage());
}

ChatGPT 如是说：
在这段代码中，虽然看起来 cache = new OneValueCache(i, factors) 这一行在没有同步机制的情况下，似乎是线程不安全的，但实际上由于 volatile 关键字和 OneValueCache 对象的不可变性，使得 VolatileCachedFactorizer 在多线程环境中仍然是线程安全的。即使多个线程试图同时创建新的 OneValueCache 对象并赋值给 cache ，但因为 volatile 关键字的内存可见性特性，所有线程都会读取到最新的 cache 值。另外，由于 OneValueCache 对象的不变性，即使 cache 被新的 OneValueCache 对象替换，其他线程获取的旧 OneValueCache 对象仍然是一致和有效的，因此并不会影响程序的正确性。

@runzekk 说实话，除了少部分语言例如 Rust 这种国内都不怎么流行的，流行比较久的语言，国内外开发水平基本属于是大差不差。但是国内的确实硬性条件上有个劣势，就是对于这些库的安全测试没有别的知名三方库覆盖全面。
很多安全团队，基本都是逮着那些知名三方库做测试，像 hutool 这种，基本就是靠国人踩坑之后再改。
不是说国产开发者不如国外开发者，这是生态上的问题。就像是操作系统国内一样能开发，但是没有生态支持，始终难以壮大，这个也并非一朝一夕能改善的，我的建议是，个人支持开源，但是涉及到线上，还是尽量少用。

@runzekk 我一开始就看到了啊。我说的是“线上环境谨慎使用”，你不是觉得我说的不对吗？我问的是你觉得有哪点不对。我自己 87 楼也说了 hutool 好用啊，我从来就没有不建议个人使用 hutool 。

@runzekk 你不妨说说你的观点，我认为线上环境谨慎使用开源库，你觉得我说的不对，那就是线上应该无脑使用开源库咯？只要是开源，就应该优先考虑？希望你能知道，开源本身并不意味着高人一等，相反，开源一定是相对 unstable 的，你如果真的想讨论，没必要总是在反驳别人，你可以说说你的想法，你要是说的对，也可以说服别人。

@runzekk 我不知道你怎么理解为因噎废食的。

线上出问题 -> 找到了 bug -> 评估三方库风险 -> 建议谨慎使用

Spring 的问题是多，但是即使 Spring 这么多问题，我至今没有遇到任何一个导致服务器宕机的问题。
但是 hutool 确实导致线上服务器宕机了。

如果说一个开源库已经导致线上事故了，还要说不使用是因噎废食，那我评价只有一个字：孝

@runzekk 1. 42 楼，json 工具类的问题
2. 我没有说国外 = 线上稳定，而是 46 楼的观点，知名三方库的重大漏洞传播更快，在真正出现问题之前修复的可能性显然更大，而 hutool 显然目前还做不到这一点。

关不关开源什么事我不清楚，但是我提到的这个 json 工具问题显然完完全全是 hutool 的 bug ，跟其他开发没关系。

@runzekk 你的观点有一个误区。对国内开源的支持是没问题的，生产环境尽量谨慎使用开源库也是没有问题的，这两者本身就可以是不同场景。
生产环境比起对开源的支持，首先是要对公司负责，就像我楼上提到的例子，hutool 某些版本确实存在一些可能导致线上服务器问题的 bug 。这种时候，“自己觉得 hutool 不好不如考虑下加入开源一起维护”这个观点完全就属于是本末倒置了，因为你首先要做的是保证线上环境的稳定。（而且也不是说不能用 hutool ，是指要用的话，就要定期检查是否存在重大漏洞修复）

对待这个问题不能二极管，hutool 确实能够给开发带来便利，但是这并不影响在没有严格的三方库风险控制的情况下，尽量别用 hutool 上正式环境。如果是个人项目，怎么用都行。这本来就不是一个 hutool 到底好不好用的问题，而是一个在生产环境引用是否具有潜在风险的问题。单纯说好用，我也觉得好用。

说一个很多人都没提到的点吧：

比较知名的开源库一旦出问题，你获取这个问题的信息渠道会比用国内的开源库广很多。
例如 log4j 一出问题，业内铺天盖地都是转发，绝大部分时候都能在线上出问题之前进行升级。
国内的一些开源库如果存在某些漏洞，基本只会在你自己的产品线上出问题了，你才可能搜到，这也是为什么不推荐在线上环境使用的原因。

如果要用，就要自己做好对该库的信息跟踪，如果引入一次 maven 就不管了，那只会变成屎山里的一坨。

我上面说的我司踩过的坑
https://github.com/dromara/hutool/issues/2812
参考这个问题。
开源不是不能用，但是用了我相信绝大部分人不会每次都跟进最新版本的变化，修复了什么漏洞。
在这种情况下，生产环境我个人是不建议使用的。