@sneezry 确实我不应该上升，本质上来说我是对这个具体的 issue handler 在完全没有建立双向沟通的情况下直接关闭 issue 的行为不满，他就是把这个 issue 晾在那里我都能接受

@sneezry 你好，是对方先关的 issue

@mercury233
> 项目里有什么

确实，应该说明一下我在空项目、旧项目以及用 yarn create 创建的新项目中均碰到了一样的情况才提的 issue

修改后有什么我进行了描述，packageManager appeared as "[email protected]+sha256.7cb31c0a881964a22577fd84e5a9a5b11e6f49ef8aa0893036b0b68015056252".
packageManager 这个 key 的存在我认为是前端常识。

> 另一个问题没有 none 选项就看不懂了

显然 issue handler 看懂了，因为他让我设置这个

@Pencillll
> 对方没理解的时候你没有进一步解释

对方关闭了 issue ，合理推测对方理解了，至少对方自认为理解了

> 把前面的谜语

“禁用了所有插件”我不认为是谜语
对方提供了解决方案，设置"npm.packageManager"，然而我在上面就已经说过了，这个配置不能解决问题，我也不认为这是谜语

大哥你让我血压更高了

@Pencillll 指责的原因是因为 handler 直接在我能够提供更多信息之前二话不说把 issues 关闭了，我的预期是通过沟通来了解对方希望获得我的环境中的什么具体信息，在我没有排查手段之前我认为这是合理的思路。

@airyland 有道理，被高血压冲昏了头脑

@Pencillll 步骤不详细是因为这个问题简直是随机产生的，我当时本身也没有明确的办法定位到问题跟因，考虑到 vscode 存在非自由部分，我当时的考虑是闭源组件导致了这个问题。
后续琢磨了下，提了 PR 来解决这个问题，这也不需要他们来修了 https://github.com/microsoft/vscode/pull/210601

对于“谜语”，我认为我把我的疑问描述清楚了，我没有进一步的信息可以提供。

禁用所有插件值得怀疑吗？ code --disable-extensions ？

@mikaelson 300k/s 的问题听起来像是 SSH Protocol 的 overhead ，20M 的小水管本身也不快

* 校验协商的双方都和自己本机在同一个 tailnet 中

@mikaelson @ZedRover 要搞清楚各个部分解决的是两个不同的问题
headscale 解决的是控制面通信问题，适用于无法与 tailscale 控制面通信的环境（当然最开始也是解决 tailscale 控制面可信问题），tailscale lock 解决的是 tailscale 控制面是否可信的问题，而 verify client 解决的是 derper 不允许其他用户通过你的 derper 握手和转发流量。derper 只是一个握手的协商者和*加密后*流量的转发者，并不涉及网络的可信问题，别人用你的 derper 顶多耗费你的流量。verify client 的行为是在协商前校验协商的二者的身份。
我觉得还是执行一个 step 之前先搞明白这个 step 的目的是什么吧（

@mikaelson 其实。。也可以，不过如果想彻底杜绝外网流量也可以用 headscale ，毕竟节点需要和控制面通信

控制面 authenticate 一个 node 的时候会把这个 node 的公钥分发给所有节点，所有节点以后就都信任这个公钥了，类比你在.ssh/authorized_keys 里加上你的 ssh pubkey 。这样的话假如 tailscale 偷偷给这个公钥列表里加上一个恶意 node 的公钥，你的内网 infrastructure 就暴露给这个恶意 node 了，如果你还配置了诸如 tailscale ssh 的东西那就影响面更大了