Win32 API 层面是采用文件路径作为标志符的。
至于文件移动，这个文件在文件系统结构上的位置都改变了，更别说移动到其他盘了，肯定是完全变了的，你可以把移动到其他盘的操作理解为在另一个盘复制一份原来的文件，然后把原来的文件删掉。

不过如果仅限于 NTFS/ReFS 的话倒是有一种解决方案：给你想要跟踪的文件创建一个 ADS （ alternative data stream ，即一个文件支持同时拥有多个数据流），里面写上 id 数据。这样 Windows 在复制 /移动文件的时候就会连同文件的 ADS 一同带上，然后你只需要检测文件是否有你设置的这个 ADS 以及 ADS 的内容就可以了。你可以把 ADS 理解为 xattr 的高级版本（因为 ADS 允许你存储任意的数据，并且不限数量和长度，而不只是 xattr 的那种属性）。

@LeegoYih 虽然但是，Go 的协程是 stackful 的，而 C++、C#、Rust 、Python 的协程才是 stackless 的

Teams 桌面客户端是 electron+angularjs （对没错，是 angularjs 1.0 ）做的，性能能好到哪里去。
现在新的要换 Edge WebView2+React 了，性能就好了不少。
但是只要还是基于 Web 的技术性能就不可能好到哪里去，跟 native 的没法比。

因为 30.x 虽然修了内存泄漏问题，但是有其他的恶性 bug 比如渲染错误等，导致微软一直没赶上。内存泄漏在这其中都算小 bug 了。
猜猜 Intel 的独立显卡为啥一直在延期？因为显卡驱动问题太多了来不及修完。

提高程序员的门槛，先要经过至少 8 年的学习，然后再考程序员证才能当程序员，当上程序员了还要每年发期刊评职称，职称越高待遇越好。

@hez2010 至于体积的话，NativeAOT + Compress 发布最后可以得到一个不到 20mb 的单文件 exe ，算上全部依赖也就 30mb

Avalonia 11.0 配合 FluentAvalonia 2.0 等于跨平台的 WinUI 3 ，并且还支持 NativeAOT 。

@bthulu IComparisonOperators 是 .NET 7 的

针对数学的泛型是在 C# 11 才引入的，所以需要 .NET 7 ，目前发了 RC 版本。

第一个问题：

可以使用 `IComparisonOperators` 作为约束：

```csharp
using System.Numerics;

static bool Between<T>(T i, T[] range) where T : IComparisonOperators<T, T, bool>
{
return i >= range[0] && i <= range[1];
}
```


第二个问题：

你直接用 `List<Animal> list = new List<Animal>()` 就行了，然后可以调用 `list.Add(new Dog())` 和 `list.Add(new Cat())` 往里面添加狗或者猫。

.NET 泛型可以向上或者向下转类型，这个分别叫做协变和逆变，只能在接口上用，例如：

```csharp
void Test1(IFoo1<object> s)
{
IFoo1<string> x = s; // ok
}

void Test2(IFoo2<string> s)
{
IFoo2<object> x = s; // ok
}

interface IFoo1<in T> { }
interface IFoo2<out T> { }
```

在 VM 里面装上杀毒软件，然后宿主机上的 WD 把 VM 的磁盘文件添加信任就行了。

何必呢，直接存储到系统自带的安全位置不就行了。比如 Windows credentials manager

win10 有几个版本确实如此，但是我升级到 win11 之后就没遇到过这种问题了。有时候内存飙到 98%占用也不卡（我电脑内存只有 8G ）

wasm 在有 JIT 的时候比 js 强，但是比原生还是要差远了。

可能是被滥用了吧，比如有人往外面的人卖教育账户，于是部分用户被限制登陆了。

@poorcai 一般没人写成 dotnet ，而是写成 .net ，但是也不排除有公司特立独行写成 dotnet

@Maboroshii dotnet run 直接跑是 Debug ，需要加 -c Release ，而 go 默认是 Release 。你在用 .NET 的 Debug 跟 go 的 Release 做比较，当然显得 go 跑得更快占用更低。

@statumer 你这举的例子跟 bash 有啥关系啊，只是在调用系统里的可执行文件而已。
Linux 上用 PowerShell 照样可以直接 ln -s foo bar 和 grep

开源协议的区别向来不在是否甩锅和担责上，因为大多数开源协议都是 no warranty 的，包括 GPL 和 MIT 都是如此，意味着都是没有保证的，出了问题也不能甩锅回去。而项目是否有保证则是由项目作者或者背后的公司单独承诺的，例如有的项目尽管使用了 MIT 或者 GPL 协议，但是其背后的公司有额外的免费或收费支持方案。
至于 GPL 和 MIT 最明显的区别，在于 GPL 自身的传染性将项目用途限制在了开源中，而 MIT 就无此限制。部分开发闭源产品的商业公司甚至不允许员工查看 GPL 代码，否则难以证明员工给公司编写的代码中不包含 GPL 代码。
这也是为什么说 GPL 是一种商业不友好的协议。
举两个例子：
1. Google 开发安卓做的第一件事就是在内核之上编写一套 Apache 协议开源的 HAL ，将 GPL 协议的 Linux 内核彻底和安卓的驱动模型隔离开，使得其他厂商都能无需接触 Linux 内核而只对 HAL 来进行驱动开发，因此不会对自己的驱动代码造成污染，也不需要开源自己的驱动代码，开源的部分只有 Google 做的 HAL 就够了。
2. Microsoft 的 WSL2 有着优秀的 GPU 支持，同样也是利用 WDDM 将 Linux 内核和驱动模型隔离开，各厂商只需要面向 WDDM 提供支持 D3D12 的驱动就能用在 WSL2 中进行硬件加速，而无需开源自己的驱动代码，开源的部分只需要是 Microsoft 的 Linux D3D12 用户态驱动。
可以看到无论是安卓还是 WSL2 ，各厂商都积极进行了跟进（ WSL2 更是在 GPU 加速预览版发布当天 Intel 、AMD 、NVIDIA 就直接推出了自己用于 WSL2 的 GPU 加速驱动）。而安卓也好，WSL2 也罢，这些图形上的生态没有一个反馈到了 Linux 自身上，大家都在用实际行动把 GPL 协议的 Linux 隔离开，确保自己的系统是商业友好的。

@nothingistrue 然而你对 GPL 的理解也是错的。GPL 也是 no warranty 的，这在协议中写的很清楚，同样有避免被甩锅的属性。