Три прохода

1. Проход 1 - пробуем без блокировки. Каналы залочены в lockorder (сортировка по адресу), обход идёт в pollorder (случайная перестановка). Готовый case - это непустая противоположная очередь ожидающих, либо место/данные в буфере, либо закрытый канал на приёме. Нашли: обмен, разлочить всё, вернуть индекс.
2. Проход 2 - встаём в очереди. Если готовых нет и default нет, на каждый case заводится свой sudog и встаёт в sendq или recvq нужного канала. Потом gopark: горутина уходит в _Gwaiting, все локи отпускаются, поток ОС продолжает работать с другими горутинами.
3. Проход 3 - уборка. Кто-то пришёл на один из каналов, выиграл гонку через CAS на g.selectDone, передал значение и вызвал goready. Проснувшись, selectgo снова берёт все локи и снимает свои sudog со всех очередей, возвращая их в кэш.

Две неочевидные детали

• Зачем сортировка по адресу. Два select в разных горутинах могут пересекаться по каналам. Если бы один брал локи в порядке A, B, а другой в порядке B, A, вышел бы классический дедлок на внутренних локах рантайма. Глобальный порядок «по возрастанию адреса» это исключает.
• Зачем CAS на selectDone. Горутина стоит в нескольких очередях, и два разных канала могут одновременно решить, что партнёр именно она. CAS 0→1 определяет единственного победителя; проигравший видит, что горутина уже занята, и идёт искать следующего в очереди.

Что было бы при проверке сверху вниз

for {
    select {
    case <-ticker.C:      // если бы порядок задавал приоритет,
        report()          // тикер раз в 10 мс всегда был бы готов,
    case j := <-jobs:     // и вот эта ветка не выполнилась бы никогда
        handle(j)
    }
}

Со случайным выбором обе ветки в среднем берут по половине готовых итераций, и порядок, в котором разработчик написал case, ни на что не влияет.

Три эффекта, ради которых это сделано

• Нет голодания. Ни одну ветку не заглушит соседняя, какой бы «горячей» она ни была.
• Перестановка веток не меняет поведение. Значит, рефакторинг безопасен, а ревьюер не должен держать в голове приоритеты.
• Расфазировка одинаковых воркеров. Пять горутин с одинаковым select не выстраиваются в одну и ту же последовательность решений.

Как именно реализована случайность

В selectgo массив индексов перемешивает алгоритм Фишера-Йетса, а случайные числа даёт быстрый потоковый генератор рантайма (cheaprandn, состояние живёт в m, без блокировок и без обращения к math/rand). Перемешивается только pollorder, порядок опроса; локи (lockorder) берутся строго по возрастанию адреса.

// Неблокирующий приём
select {
case v := <-ch: use(v)
default:        // канал пуст
}

// Неблокирующая отправка
select {
case ch <- v:
default:        // буфер полон / получателя нет
}

// Неблокирующая проверка отмены
select {
case <-ctx.Done(): return ctx.Err()
default:        // не отменён, считаем дальше
}

Ключевое свойство: атомарность

Проверка «готов ли канал» и сама операция идут внутри одной критической секции под локом канала. Поэтому select/default нельзя заменить на if len(ch) > 0 { v := <-ch }: между if и чтением значение успеет забрать другая горутина, и ты заблокируешься.

Где применяют по делу

• Телеметрия и логи: лучше потерять сэмпл метрики, чем притормозить обработку запроса.
• Сигнальные каналы с буфером 1: «есть новая работа», и если сигнал уже лежит, второй не нужен.
• Дренаж: забрать всё, что уже накопилось, и уйти.
• Периодическая проверка отмены внутри долгого вычисления.

Такая горутина не потребляет CPU и не занимает поток ОС, она просто выпадает из планировщика насовсем. Разбудить её нечем: у неё нет ни одного sudog ни в одной очереди.

Единственное осмысленное применение

func main() {
    go worker()
    go metricsServer()
    select {}     // «главная горутина, повиси, пока работают фоновые»
}

Логика такая: main завершится и утащит за собой весь процесс вместе со всеми горутинами, а фоновые должны работать дальше. В реальном сервисе это всё равно почти всегда плохое решение.

В selectgo case с nil-каналом просто пропускается при опросе и не получает sudog. Поэтому он не мешает остальным, не тратит ресурсов и никогда не выигрывает. Если все каналы nil и default нет, горутина заблокируется навсегда, ровно как на select {}.

Паттерн 1: отправлять, только когда есть что

var out chan Result          // nil, пока результата нет
var pending Result
for {
    select {
    case v := <-in:
        pending = compute(v)
        out = results        // включаем ветку отправки
    case out <- pending:
        out = nil            // выключаем: отправлять больше нечего
    case <-ctx.Done():
        return
    }
}

Без этого приёма пришлось бы либо крутить default-цикл, либо отправлять нулевые значения, либо разводить два разных select и дублировать в каждом логику отмены.

Паттерн 2: аккуратное завершение при закрытии одного из источников

// merge двух каналов: закрывшийся источник обнуляем, чтобы не крутиться на нём вечно
for a != nil || b != nil {
    select {
    case v, ok := <-a:
        if !ok { a = nil; continue }   // закрытый канал всегда готов, поэтому обнуляем
        out <- v
    case v, ok := <-b:
        if !ok { b = nil; continue }
        out <- v
    }
}
close(out)

Таймаут

// Разово можно и time.After
select {
case v := <-ch:
    return v, nil
case <-time.After(5 * time.Second):
    return zero, errTimeout
}

// В цикле только переиспользуемый таймер
t := time.NewTimer(5 * time.Second)
defer t.Stop()

Отмена по контексту

select {
case v := <-ch:
    use(v)
case <-ctx.Done():
    return ctx.Err()      // context.Canceled или context.DeadlineExceeded
}

Так лучше, чем time.After: дедлайн приходит сверху, его наследуют все вложенные вызовы, снимает его явный cancel(), и лишних таймеров не плодится.

Graceful-цикл воркера

func worker(ctx context.Context, jobs <-chan Job, out chan<- Result) error {
    tick := time.NewTicker(time.Minute)
    defer tick.Stop()
    for {
        select {
        case j, ok := <-jobs:
            if !ok {
                return nil                  // 1) продюсер закрыл вход, выходим штатно
            }
            r, err := handle(ctx, j)
            if err != nil {
                return err
            }
            select {                         // 2) отправка результата тоже отменяема
            case out <- r:
            case <-ctx.Done():
                return ctx.Err()
            }
        case <-tick.C:
            heartbeat()
        case <-ctx.Done():
            return ctx.Err()                 // 3) внешняя отмена
        }
    }
}