这个问题的核心是你业务逻辑的“线程安全”是如何定义的（只有你自己知道），至于是用锁、读写锁、Semaphore 、无锁、volatile 等，这些纯粹是实现细节，取决于你对并发相关基础知识（操作系统领域）以及特定语言（这里是.NET ）相关库和语法的熟悉程度。

由于不了解你的业务逻辑实现细节，我只能提问：

- 线程 0 是只写吗，是否依赖 Device 当前的状态？
- 监控线程统计所有设备状态时，以及执行异步操作时，是否允许线程 0 进行更新？
- 监控线程的异步任务与线程 0 是否存在写入相同的内存区域的情况？
- 监控线程的异步任务是否可能执行超过 100 毫秒，如果超过，是否允许多个监控线程的异步任务同时执行？如果允许，它们的写是否冲突？

你至少需要补充以上细节，才能让回答者更好的帮你解决问题。

同步、异步、阻塞、非阻塞，本来就没有一个精确的定义，很容易因为理解不同而鸡同鸭讲，个人博客更是造成理解冲突的重灾区（个人博客充斥着二手知识，用词并非精确）。

“异步”和“异步 IO”当然不是一回事，“异步”可以用来描述任何一段子程序的执行方式，而“异步 IO”，只能用来描述 IO 操作（读写文件和网络等）的执行方式。

按照 Unix 的 IO 模型（《 Unix 网络编程卷 1 》，6.2 IO 模型），同步和异步用于描述内核和用户空间之间数据复制的过程，而阻塞和非阻塞用于描述等待资源就绪（网络资源、文件资源等）的过程。

在某些书籍、博客中，或者非 IO 操作的上下文中，会相对抽象，将`阻塞`和`同步`都解释为等待，将`非阻塞`和`异步`都解释为立即返回，我无法评价这种解释是否正确，但至少在 Unix IO 模型中，这种解释是错误的。
------
回归正题，“Go 中的网络编程模式”，你的困扰无非是该用其底层实现，还是其提供的 API 风格来描述，我个人是倾向于后者，但除非 Golang 团队亲口所说，纠结用什么定语来修饰“Go 的网络编程模式”没太多意义。

Vue 项目用 electron,wails,tauri 等 web ui 解决方案打包成桌面端程序。

java 项目有技术就用 graalvm 编译成 exe ，没技术可以安装 JRE/JDK ，或者绿色版 JRE/JDK 。

Nginx 是什么鬼，本地部署哪里需要 Nginx 。

这其实就是 shadowsocks,clash for windows,clash verge 之类翻墙软件用的解决方案，去看看它们的源码就懂了。

唯一麻烦点就是 java 程序需要虚拟机，比纯 exe 麻烦点，但你想想，IDEA 还不是照样自带了个虚拟机。
------
归根到底，你这项目最佳的部署方案就是桌面端 GUI 程序。

相应的功能在 chrome 下能通过吗，你先按照 Chrome v3 的相关文档来开发，最后再考虑兼容性问题。

@CLMan 补充：
1. “函数内部代码会貌似会同步执行”，我理解了，你指的内部代码会作为一个整体被执行，这是正确的。返回 Future 是语法层面的规定，表示这个异步函数的异步执行情况。正如我上面所说的，返回结果会自动包装为 Future ，比如 B 函数，熟练以后是这样：

```dart
//省略上面内容
return "请求到的数据：" + result.toString();
```

1. JS 的 async 会将返回结果自动包装为 Future ，Dart 也是类似的原理。异步函数会异步执行，返回结果为 Future 类型，跟里面是否使用 await 没什么关系。

你所认为的同步，其实只是因为你这测试用例过于简单，只有 A,B ，给你带来的错觉。

2. 你为什么会认为“遇到 B 函数的 Future.delay 时直接返回了 Future 对象给 A”，你用打印下结果就知道不是你想得那样：
//修改 A 函数的 print(B());为：
var result = B();
result.then((value) => print(value));

3. await 有两个作用：1. 让“await doSomething()”的 doSomething()异步执行（ JS,DART 就是“抛事件循环”，其它语言可能就是多线程、协程等） 2. 等待 doSomething()对应的异步任务执行完成，然后再执行剩余部分。所以只有 B 执行完后，才返回执行 A 的后半部分，也就是你说的“同步调用 B 函数第一行打印语句”。

“抛事件循环”，是一种抽象化的模型，容易让人理解得云里雾里。沿用这种模型来说明，应该是先抛 B()到事件循环，再抛 A 的剩余部分到事件循环。

事实上，当 JS 和 Dart 的代码混合了异步逻辑，很难只用事件模型来描述代码的执行情况。比如，假设 B()函数里面`await C()`，那 C()是不是就抛到 A 的剩余部分后面了，岂不是 A 的剩余部分还先于 C()执行。当然，你可以再给这个模型补充很多细节，问题是这些细节就牵涉到具体的实现，比如 chrome,mozilla,quickjs 等完全可以采用不同的底层实现。

这并不是说事件模型是错误的，只是说当存在异步逻辑时，事件模型需要补充很多细节，不然就会像你一样陷入混乱，此时可以不用事件模型来理解程序的执行。

4. 不了解，我这里 IDE 提示：“可以去掉 await ，且 await 无效”。无论是还是不是，这种代码没有啥实际价值。

@CLMan 补充下，默认导出目前还是有一些应用场景：

- 使用 JS/TS 作为配置文件，rollup,jest,vite 等框架的配置文件都是采用默认导出

除了以上场景，一般情况下自己的代码都没有必须使用默认导出的必要。

洋洋洒洒写了那么多，其实最关键的继承家业却没提，属实典中典了。

@CLMan 我翻了下 ECMAScript 的早期相关讨论，终于找到了一个相关文档： https://archives.ecma-international.org/2014/misc/2014misc6.html 。

这个文档证明了我的以上猜测，默认导出设计的初衷就是为了兼容类似 jQuery 这样 ES6 之前的流行的 JS 使用模式（全局单例对象），也确实如文档所说，给当时的 JS 使用者以及后来的 JS/TS 使用者造成了混乱。

这是典型的编程语言设计时因缺乏长远考虑，给后来的使用者带来困扰，后来的使用者还必须得考古才能理解其应用场景，了解语言的缺陷仅为了避免使用该缺陷是当代的编程语言学习者常常面临的情况。

这个可以参考 google typescript style guidle ，只需要使用 1 ，不建议使用 2,3 ，也没有什么必须使用 2,3 的场景。

至于上面说的桶文件，其实更多是基于兼容性和习惯（ Deno 作者吐槽为设计错误），并不是说这种设计就是好的。通常情况下，仅限于包级别使用（ src/index.js ）。

如果考虑浏览器兼容，需要 iife 模式（脚本模式），rollup 对 1,2 产生相同的结果，因此也不需要必须使用默认导出。

我也不知道当初 es 是为啥设计默认导出，我一直以来猜测是为了兼容 iife 模式，一个库提供一个全局对象，避免污染 global 作用域。但没有证据能证明我的猜测。

可以从学历，年龄，知识，经验四个维度来评估自己。从个体上来讲，一切皆有可能。从群体大数据上来讲，在这行业以 **技术** 立足的可能性微乎其微。

你目前的情况可能也就本科计算机大二水平，而人家有学历（学习能力）、年龄的优势。

如果只是单纯当个兴趣，可能也就 python,javascript 适合没有太多计算机科学背景的人学习，用来完成一些自己的项目。

如果你 10 年前说出这样的话，说明你有远见。

但今天再说这样的话，就属于正确的废话，放自己笔记或者丢评论区没啥，发帖就属于浪费大家时间。

因为`func (h *IntHeap) Pop()`是 golang 的 heap 的实现细节：

type Interface interface {
sort.Interface
Push(x any) // add x as element Len()
Pop() any // remove and return element Len() - 1.
}

而真正堆的 pop 方法是`heap.Pop()`函数，别把两者弄混了。

两个内存大户，谈体验的话，都谈不上好。

@CLMan 补充一下，我实际测试过：

- eol 设定不存在强制效果，只会在提交时当本地文件的 eol 与设定和存档文件均不一致时才提示转换
- 如果本地文件的 eof 与存档文件的 eof 一致，即使违背了 eol 设定，那么 git 不会提示也不会转换

·EOL·是 end of line 的缩写，表示仓库中文本文件应当使用的换行符，可以通过`core.eol`（ etc/gitconfig,~/.gitconfig ）来设定，或者.gitattributes 的`* text=auto eol=lf`类似指令来设定，默认为 native 。

`core.autocrlf`（ etc/gitconfig,~/.gitconfig ）可以指定当文件的 eof 与设定不同时，是否在检出和提交代码时进行转换。

回答里的问题：

1. “在 windows 查看文件 a 、b 的 eol 格式都是 crlf”，因为你没在~/.gitconfig 中设定，所以使用 etc/gitconfig 里面的默认设定，如果你是手动安装的 git ，在你安装时的选项会最终保存在该文件，不同 client ，比如 github desktop 或者 fork 等，可能会使用它们自带的 git
2. “在 linux 查看文件 a 、b 的 eol 格式都是 lf”与 1 同理
3. “ZIP ，查看文件 a 为 crlf ，b 为 lf ”，ZIP 里面存储的是原始文件，并不会受到 autocrlf,eof 的设置影响

特别是 3 ，这些设置本质上是影响 git 这个软件的逻辑，并不会直接影响实际存储的数据

@drymonfidelia 在我本机上实测，可以正确设置 header 。