那就整改啊，上 HTTPS 和 mtls ，让他防火墙检测不到，不就“安全”了吗？

一行的 shell 命令直接 C-r 就好了。
其余的用 vscode 的 snippets

不要这样滥用，pip 安装命令行程序本身就很糟糕，你还不如上 npm 。

建议写个 brew formula ，mac 和 linux 都可以用。Windows 的话以前都用 scoop ，也可以看看微软自己的 winget ，听说已经内置了。

@leeg810312 同步异步都有不外乎：
1. 该平台早期就没有异步，异步是后来加的。
2. 异步有较大的复杂度，不值得总是使用。
3. 底层无运行时的语言，当然需要都支持。

async/await 无论哪个实现形式都是一样的：函数转换成一个状态机，内部的 await 作为显式的 suspend point ，当执行到的时候将函数挂起，状态保存，然后控制流返回给 runtime 。runtime 在某个时间点再次 schedule 该 task ，直到结束。
异步 context 中调用阻塞操作会使 runtime 无法拿回控制流，整个线程就被阻塞了，而不单单是一个 task 。而这个线程是 runtime 的 worker 线程。如果 runtime 有 10 个 worker 线程并发处理一万个 task ，那么阻塞一个就只剩 9 个线程可以执行其他 task 了，并且由于 task 都是写并发的，代码里有阻塞部分大概率不止会阻塞一个线程，这样就会导致整个系统的吞吐量大幅下降，也就是阻塞整个 runtime 。

kotlin 则是完全不同的模式，虽然和 async/await 有一定的相似性，但这和调度器有啥关系？

@liuhan907 我说 gc 是因为 gc 语言的应用场景主要是写业务和应用，只要在该执行的时候执行就好，不关心具体如何调度。同时 gc 语言也不在意一些小小的 overhead ，所以可能并不值得 async/await 造成的过度的复杂度。我倒是不了解确实有这种需求，所以请教一下你这个例子中如果并行了会怎样？或者说为什么不能简单的用 task 处理所有的任务？

你是说返回的 data.baidu 字段名是动态的，其他结构不变？
那把 Data 改成 map[string]Baidu

@locoz 比起正常的 Linux 发行版阉割太严重，包管理器不能更新整个系统。
我个人是推荐 opnsense 的，但如果有人喜欢爱快的流控那也没问题，核心是把魔法部分抽出来跑在一台单独的设备上，插上能 xx ，拔下来也能正常用，与路由器解耦。

@leeg810312
比如我要写一个 redis client ，需要用同步 IO 的 API 和异步 IO 的 API 分别实现一遍，代码逻辑完全一样，为什么不能只写一遍？除了底层语言没有必要同步异步都有，像 go 、erlang 可以全都是异步，异步不增加任何额外的复杂度和学习成本。green thread 也没有这个问题。
至于真正需要全都有的，可以了解一下 zig 的 color blind async ，只需要实现一遍，同步 context 下 async 自动变成 noop 。

异步 context 调用同步方法导致阻塞就是 async/await 模型的缺陷。你要说是实现的问题，你到说说哪个 async/await 的实现可以调用同步方法而不阻塞？

贴里讨论的一直都是 programming pattern ，根本没有提到过 scheduler/runtime 具体实现的问题，上面讨论的也是 task 具有 structural 的特性(await task will resume after all sub task awaited finished)从而可以更细粒度的控制不同的 task 由不同的 executor （单线程 /多线程）执行。这确实是 async/await 比 goroutine 的优点，但如果 green thread 引入了 structural concurrency 也是一样可以实现的。

async/await 在过去一段时间确实非常流行，但没有任何范式可以适用于所有的需求，没有银弹，自然没有哪个能成为是“最好”。
何况 async/await 有很多问题和批评， 如 https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ ，hn 上每几个月都上一次头条，没看过可以看一下。

建议多了解一些不同的语言和范式，C#是一门优秀的语言，但它也有历史的局限性。很多当时的设计但若干年后发现有问题的（比如 void 不能作为泛型参数）。erlang/elixir 可以写出天然分布式的程序，actor model 广泛在 OOP 中使用，green thread 极大的简化了异步 IO 的复杂度，直接编写同步代码并获得异步 IO 的并发性能提升 nearly for free 。structural concurrency 是 trio 的作者提出的，要求任何函数 spawn 的 task 必须在函数返回前结束，希望像现代编程语言的控制流取代 goto 一样取代当前 spawn 的 task 可以自由运行 for any time ，详细阅读 https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
go 里的 errgroup 和 rust 的 scoped_thread 都是该范式的体现，并且被 kotlin 作为了官方的协程范式。

@Higurashi

ByteBuffer.getFloat
DataInputStream.readFloat

这是处理二进制数据时非常常见的情况，不会不好找。

@leeg810312 没有银弹，不同模型都有自己的优劣，没有哪个是“公认最佳”。
我一直说的都是“异步编程模型”，以 goroutine/fiber 为代表的 green thread ，以 erlang 为代表的 actor model ，以 trio 和 kotlin coroutine 为代表的 structural concurrency ，以及经典的 async/await 。
说它难用主要体现在两个方面：
1. colored function 。几乎所有的库 /函数都要实现两遍，sync 和 async 的版本。
2. blocking 。async context 里调用同步操作 block 整个 runtime 。
当然还有代码里到处都是 async/await 关键字，不过这个属于个人偏好。
你要说不同平台的具体实现，还有 future based (do nothing until awaited) 和 task based (spawned after creating)的区别。无运行时的语言没法使用 green thread ，有 gc 的语言（尤其 Python 的 asyncio 选择前者）用 async/await 并不能说是良好的选择。js 因为最开始就是异步单线程降低了复杂度同时也确实优于回调模式。Rust 的实现还相当不完善，实现自己的 future 还需要 unsafe ( pin projection)。Swift 不了解就不评价了。

如果你想从 byte 得到 float 的话，还需要考虑 endianess ，建议用专门的库。

@liuhan907 gc 语言的使用场景下一般不需要关心这种问题，尤其 go 这个号称“大道至简”的 opinionated 语言，更是几乎不在意任何 corner case 。不能为特定 task 自定义调度器是 go 的并发模型缺乏 structural 的问题，而不是 green thread 隐式插入 suspend point 本身的问题。如果支持 scoped thread/task 的话，理论上也是可以实现的。我只想到了 FFI 需要防止 task 被 move 到其他 thread （并且与 ffi 的交互也应该被包装而不是影响到上层的行为），除此之外这应该属于运行时提供的抽象层，如果正常写业务的时候需要关心那这个抽象就是 leaky 的。
所以我想知道，有什么具体的，gc 语言的使用场景下，无法包装且需要对某些特定的 task“只并发不并行”的需求呢？

@liuhan907 因为用 gc 语言一般不追求 precise control ，也就没有必要显式标识 suspend point 。

goroutine 确实不能为特定的 task 专门配置 executor ，但我觉得这是个 structural 的问题，即 spawn 一个 task 之后无法追踪该 task 后续 spawn 的其他 task 。与隐式插入几个 suspend point 关系不大。如果要防止调用某些系统 API 的时候 goroutine 被 move 的话 runtime.LockOSThread 就可以，能说说有什么场景 gc 语言需要关心 task 具体怎样调度么？

@liuhan907 在 gc 语言中你真的需要控制 suspend point 吗？

如果你家里有不同的设备需要划分网段分别管理，那就不要用 ipv6 。Android 始终坚持不实现 DHCP v6 stateful 地址分配，导致用了 ipv6 就没法管理地址了。

配置了相同的静态 IP 地址 / 配置了相同的 mac 地址 / 配置了相同的 DHCP UUID

@ly841000 color blind function,不用担心 blocking ，插桩用户无感知，不需要用户到处插入 async/await ，你到说说哪里不好？

@dalaomai 1. 容器是通过宿主机访问网络的，你应该在宿主机上设置全局代理，或者按 wireguard 推荐的方式，创建相应的 tun 然后移动到容器的 namespace 里。需要注意 tproxy 与 docker 网络栈有所冲突。
2.绑定对应的接口指的是你的应用 bind to the network interface which is reachable ，比如为了安全起见很多程序默认不会绑定到 wan interface 。

@Removable 语法啥的先不说，最主要的是 colored function 和 blocking 的问题。有运行时的语言 goroutine 或 actor 都是不错的模式，kotlin coroutine 实现的 structured concurrency 也还可以。相比之下 c# 和 py 等 (js 由于异步单线程的原因感觉上还好) 就比较难用了，当然 rust/cpp 这些无 gc 语言还有内存管理 pin 之类的问题更加痛苦。