Краткий ответ

ok_or вычисляет переданную ошибку сразу, даже если Option содержит Some. ok_or_else принимает замыкание и создаёт ошибку только при None, поэтому подходит для дорогого или зависящего от контекста построения ошибки.

Исторический контекст

Option выражает наличие или отсутствие значения, но не сообщает причину отсутствия. Result предназначен для результата, где неуспех должен содержать диагностическую информацию. Комбинаторы ok_or и ok_or_else дают единый способ перейти от простого отсутствия значения к явно описанной ошибке.

Разделение на две операции отражает важную оптимизационную проблему: значение ошибки может быть дешёвым константным объектом или требовать форматирования, выделения памяти и вычисления дополнительного контекста.

Постановка проблемы

Представим поиск записи в кэше. Если запись найдена, ошибка не понадобится. Однако при использовании ok_or выражение, создающее ошибку, вычисляется до вызова метода, поэтому его стоимость будет понесена даже для успешного результата.

Это не меняет итоговый тип или семантику успеха: при Some(value) оба метода возвращают Ok(value), а при None — Err(...). Отличается момент создания ошибки и, следовательно, побочные эффекты, производительность и доступность локального контекста.

Подробное решение

ok_or принимает уже вычисленное значение ошибки. Условно сначала создаётся E, затем метод проверяет Option; поэтому он уместен для дешёвых ошибок, например статического значения или небольшого перечисления без дополнительных данных.

ok_or_else принимает замыкание FnOnce, возвращающее ошибку. Замыкание вызывается только в ветви None, а его окружение может захватывать контекст, необходимый для сообщения или структуры ошибки.

fn port(value: Option<u16>, name: &str) -> Result<u16, String> {
    value.ok_or_else(|| format!("параметр {name} не задан"))
}

fn main() {
    assert_eq!(port(Some(8080), "port"), Ok(8080));
    assert_eq!(port(None, "port"), Err("параметр port не задан".into()));
}

В успешном случае замыкание форматирования не выполняется. В неуспешном случае оно создаёт ошибку, которая затем возвращается как Err.

Выбор метода не должен использоваться для сокрытия действительно ожидаемой неопределённости: если отсутствие значения нормально и не является ошибкой, лучше оставить Option. Преобразование в Result оправдано, когда вызывающему коду нужно различать отсутствие и продолжить обработку через общий механизм ошибок.

Ситуация из практики

Сервис читает необязательный заголовок запроса и должен вернуть структурированную ошибку с именем заголовка. Вариант с ok_or может использовать заранее созданную простую ошибку, но при динамическом сообщении форматирование будет происходить и для корректных запросов. Это увеличивает ненужные расходы и может усложнить владение строковыми данными.

Вариант с ok_or_else откладывает форматирование до фактического отсутствия заголовка. Его минус — дополнительное замыкание и чуть более сложная запись, но для динамического или дорогого построения ошибки это разумный компромисс. В результате успешный путь не выполняет лишнюю работу, а ошибочный сохраняет нужный контекст.

Что кандидаты часто упускают

Вопрос: Можно ли считать ok_or_else ленивым относительно проверки Option?

Ответ: Нет. Проверка Option выполняется методом немедленно. Ленивым является только вычисление значения ошибки: замыкание вызывается после обнаружения None. Поэтому ok_or_else не откладывает саму операцию поиска или получение Option, а только создание Err.
Вопрос: Может ли замыкание в ok_or_else изменить исходный Option?

Ответ: Оно не получает сам Option автоматически и не меняет его внутреннее состояние. Замыкание может захватывать внешние переменные по ссылке или владению, поэтому теоретически способно изменить захваченное изменяемое состояние, если это разрешают правила заимствования. Это побочный эффект самого замыкания, а не особенность преобразования Option в Result.
Вопрос: Когда разница между ok_or и ok_or_else влияет не только на производительность?

Ответ: Когда создание ошибки имеет наблюдаемые последствия: записывает диагностику, увеличивает счётчик, обращается к внешнему состоянию или может завершиться паникой. ok_or выполнит такое выражение независимо от того, был ли Some, тогда как ok_or_else — только при None. Поэтому выбор метода может менять поведение программы, а не только количество затраченных ресурсов.