OP 不如使用补充功能讲清楚到底哪个不适合

根据这么多的讨论，我猜测如下——


Linux & macos 式右键（ mouse down 就跳菜单）可以实现以下功能（感谢 @NoOneNoBody 提醒）：
按住右键→跳出菜单→光标移到任意菜单项→松开右键→系统执行菜单项功能

OP 认为，这个使用方式毫无意义。


Windows 式右键（ mouse up 跳菜单）可以实现以下功能：

1. 按住右键，拖拽多选一堆文件，松开后可以自动跳出多选后的右键菜单，而不需要左键多选再右键
2. 选中单个或多个文件，右键拖到某个位置，松开，自动跳出右键菜单
3. 对于浏览器鼠标手势十分友好

对于 1 ，压缩文件时比较方便。
对于 2 ，适合压缩以及解压文件。说起来，这个我有时也会用到，比如把某个 7zip 压缩包解压到另一个文件夹（开两个窗口，或者左侧“此电脑”目录树打开），用右键拖拽解压确实比较方便，既不需要复制或移动后再解压，又不需要打开命令行敲命令）。还有打包一堆文件时也会用到，可以直接创建到目标文件夹，而不需要打包完再剪切粘贴。

OP 认为应该采用 Windows 式右键更合理。

是这样吧？

看完描述我是一堆问号。

从上下文来看，
「不明白为什么要这么设计,我唯一能想到的是 按住右键 然后移动到想要的选项 松开 完成一次菜单选择.但是有什么意义?」
这句话似乎是在表达“不喜欢 mouse up 弹菜单，因为没什么意义”

但标题以及后续两段，表达的是“不喜欢 mouse down 弹菜单，更倾向于使用 mouse up 弹菜单”

如果两个做法都不满意，我觉得唯一能够做的，就是分成两个步骤：
1：左键点击目标
2：按下键盘的“菜单”按钮
缺点是，并非所有位置都适合。

跑个题，OP 是不是铜币用完了就换个新账号继续提问？

@Huelse “微软也开始转向 rust 而有了 ReFS”？
这时间就不对吧，ReFS 正式推出时（ 2012 年），Rust 1.0 （ 2015 年）都还没发布呀。

如果单纯想查是否国内，那么 ipip net 就有。
“宽带症候群”节点那边经常用 ipip 的 BestTrace 工具查中间设备的 IP 归属。有时候稍有偏差，不过都是省市级的偏差（尤其是运营商新增设备时，IP 库记录更新没那么快），放宽到国家范围的话基本都是准确的。

但可供下载的每日更新的 IP 库并不免费。或者也可以用他们的免费 API 查 IP 。

做法很简单，用高精度游戏鼠标，可以调刷新率的那种。然后手腕关节旁最大的那块肉轻轻按住鼠标垫，当作支撑点。

随后滑动光标箭头的操作，就用手指去移动鼠标。其实手指可以移动的幅度不小的。

最关键的一点：手腕关节保持放松状态，总之控制关节的肌肉尽量不要发力。于是我的右手在握鼠标的时候，总是显得肘关节下垂。

我是重度鼠标党，别人都说自己手腕关节痛、患上鼠标手的时候，我却没事。因为在这种操作方式下，我的手腕关节极少受压。

去年就有人问过：
/t/855542
《为什么家庭宽带的上传，给的都特别少》

里面的讨论以及里面顺道提到的其它讨论贴，都讲得很详细

老老实实告诉你的老板（甚至可以把这个讨论贴给你的老板看看），新版安卓已经不能这么干了，想要录音的话就换成自带通话录音功能的国产机。

正如楼上讲的，工作相关就该用工作手机，免得录下非工作内容。

无法删除，其实就是路径长度限制 255 的缘故，自 Win10 起可以手动解除：

用组策略接触限制，立即生效
https://www.microfocus.com/documentation/filr/filr-4/filr-desktop/t47bx2ogpfz7.html

或者用注册表解除限制
https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

一劳永逸

文件的复制粘贴、剪切粘贴，可以确保源文件未经第三方“触碰”、未经修改的情况下再操作。这样剪切前后两份文件的数据都相同，可以认为是同一份。
意识可以吗？在意识上传过程中，能否确保“意识”本身 100%处于停顿状态？

再说了，意识上传能不能复制、剪切、粘贴，首先必须确定一件事，“意识”本身是什么编码类型？如果也是 Digital 那就好说，如果属于 Analog ，不好意思，直接变成玄学。

为什么说 Analog -> Digital 会变成玄学？请参考 HiFI 圈的那堆争论。

FreeBSD

仔细观察就会发现，“毛刺”出现在小核。也就是说，背景程序几乎都集中在小核处理了，出“毛刺”都算小意思了，夸张点的可以全部占满。

我用无小核的 Intel CPU ，并不会出现这种“毛刺”式 CPU 占用现象。

解决办法十分简单，不需要换系统，关掉小核即可。或者换成无小核的 CPU ，然后小黄鱼卖掉 12700K 。

TCP 是流，消息边界需要自己拆。n 确实可以少于 2 。

数据量少的时候，也许收 /发的数据看起来都是老老实实的，不多不少刚刚好。但数据量大或者受到网络延迟、丢包重传等因素的影响，这就难以保证每次 recv 收到的数据大小都一样。

例如发送端分两次分别发出“8ABCD” “EFGH”，接收端既有可能会分两次收到“8ABCD” “EFGH”这两段，也有可能会一次性收到“8ABCDEFGH”拼起来的一长串，甚至还可以是“8ABCDEFG” “H”。

所以最稳妥的做法就是循环调用 recv ，自己设好边界规则逻辑，自己从 TCP 流拆出并重新组合成实际想要的数据。

不一定是屏蔽了端口，更大的可能性是 NAT 类型的原因。

几个月前我就用移动 4G/5G 试了下打洞，发现 NAT 类型并非 Full-cone NAT ，似乎是“对称 NAT” (Symmetric NAT)，也就是 NAT4 ，或者至少是 NAT3——“端口受限圆锥型 NAT” (Port-Restricted cone NAT)

我猜，可能是因为有潜在的“ABA 问题”，所以就索性用 mutex 简单粗暴免除隐患吧？

有不同的可能性：

1. 路由器性能太差导致延迟变高
2. 运营商给腾讯的流量优先级更高

所以，先试试换个好一点的路由器

不如一步到位，直接租普通小区

@lakehylia cpp 后缀改成 c （也就是使用纯 C ），就能复现了