这是一篇关于 Go 语言中通道（channel）相关内容的文章，主要介绍了以下几个方面：

• 前言（Preface）：时隔近 6 年继续更新该系列，本次介绍一个尚未涵盖的简单模式。之前曾开发一个玩具库来验证新的泛型提案能否表达 Go 中常见的通道模式，最终决定等待社区或标准库提供更好的方案，现在分享实验中的一些经验。
• 免责声明（Disclaimer）：对于新手常问的如何创建无限缓冲的通道，答案是不建议这样做，因为这会使代码更难调试，可能导致问题隐藏。但在某些罕见情况下，如系统需要吸收突发流量或快速释放生产者时，可使用特定代码。

• 解决方案（Solutions）：

  • BufferChan函数：定义了一个BufferChan函数，其形式为func BufferChan[T any](in <-chan T) (out <-chan T)，用于处理通道，保证in上接收的值都会在out上发出，in关闭且所有缓冲值发出后out也会关闭。
  • 短时间操作且顺序不重要的情况（When order doesn’t matter and the operation is short-lived）：通过BufShortLived函数实现，该函数创建一个缓冲所有未被及时消费的值的通道，在操作结束时关闭输出通道。
  • 长时间操作且顺序重要的情况（When order does matter, and the operation lasts a while）：通过BufLongLivedOrdered函数实现，在处理通道时不使用互斥锁或条件变量，仅依赖通道语义。同时还提到可以添加一个default块来避免缓冲区不必要的增长。
• 改进（Improving on it）：在上述解决方案中添加一个default块，使代码总是先尝试发送，再尝试同时发送和接收，可能会减少缓冲区大小。
• 完整代码（Full code）：给出了BufLongLived函数的完整代码。
• 结论（Conclusions）：通过 31 行代码实现了一个从现有通道创建新的有序、无限缓冲通道的操作符，但认为这种情况很少见，建议先尝试找到合适的缓冲区大小或重新考虑架构。

• 编辑（Edit）：

  • 2024 年 12 月 20 日：指出与“真正”的无限缓冲通道相比，实现中存在一个小差异，即从源通道接收的值不会立即在输出通道上发送，可能导致一些情况无法在“真正”的通道中重现。
  • 2024 年 12 月 21 日：朋友 Roger Peppe 指出使用切片的滑动窗口作为队列实现可能导致性能不佳，尤其是处理大量值时，建议使用自定义队列作为参数的实现。