Интерфейсы io.Reader и io.Writer — бесплатный тест онлайн

Вопрос 1 из 25

Перед публикацией кода по теме «Чтение через io.Reader» нужно уточнить контракт. Что увидит вызывающий код после выполнения?

// Фрагмент для трассировки.
package main
import("io";"strings")
func main(){ r:=strings.NewReader("abc"); buf:=make([]byte,2); for{ n,err:=r.Read(buf); _=buf[:n]; if err==io.EOF{break}; if err!=nil{break} } }

Попытка сериализовать поле-функцию завершается `json: unsupported type`, а не молча пропускает его. Два последовательных объекта могут быть декодированы двумя вызовами `Decode` без предварительного чтения всего входа. Чтение `m["x"]` из `nil`-карты даёт `0`, но попытка `m["x"] = 1` завершится паникой. Чтение `<-ch` получит `7` только после готовой отправки, а небуферизованный канал создаёт точку встречи. Код сначала обрабатывает `n` байтов, а затем завершает цикл по `io.EOF`, не теряя последний фрагмент.

Вопрос 2 из 25

В рабочем примере по теме «Чтение через io.Reader» важно отделить гарантию от догадки. Как подготовить этот код к реальному использованию?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import("io";"strings")
func main(){ r:=strings.NewReader("abc"); buf:=make([]byte,2); for{ n,err:=r.Read(buf); _=buf[:n]; if err==io.EOF{break}; if err!=nil{break} } }

Использовать `DisallowUnknownFields` на строгой внешней границе и ограничивать размер входного потока. Сохранять смысл полей, добавлять версию там, где возможны несовместимые формы, и тестировать старые образцы. Всегда обрабатывать данные до ошибки и использовать `io.ReadAll`, `io.Copy` или буфер там, где они точнее выражают задачу. Выбирать байтовую обработку для протоколов и `[]rune` или пакет `utf8` для операций над кодовыми точками. Не оставлять канал `nil` случайно; намеренно использовать `nil` только для отключения ветви `select`.

Вопрос 3 из 25

Фрагмент относится к теме «Чтение через io.Reader». Какой контракт определяет результат показанного кода?

// Определите правило Go, которое объясняет результат.
package main
import("io";"strings")
func main(){ r:=strings.NewReader("abc"); buf:=make([]byte,2); for{ n,err:=r.Read(buf); _=buf[:n]; if err==io.EOF{break}; if err!=nil{break} } }

`json.Decoder` читает последовательность значений из `io.Reader` и подходит для потока или большого документа. `json.Marshal` возвращает байты и ошибку; неподдерживаемые значения вроде функций и каналов приводят к ошибке. `Read(p)` возвращает число прочитанных байтов и ошибку; допустимо получить `n>0` вместе с `io.EOF`. Добавление необязательного поля обычно совместимо со старым JSON, а переименование или изменение смысла существующего поля требует миграции. Чтение отсутствующего ключа возвращает нулевое значение элемента; запись в `nil`-карту вызывает панику.

Вопрос 4 из 25

На ревью разбирают тему «Чтение через io.Reader». Какое допущение здесь чаще всего оказывается ложным?

`Read` может вернуть меньше `len(p)` без ошибки, поэтому одно чтение не обязано заполнить буфер. Одна видимая графема может состоять из нескольких рун, поэтому даже число рун не всегда равно числу пользовательских символов. `NaN` и бесконечности `float64` не являются допустимыми числами JSON и вызывают ошибку кодирования. Отправка в закрытый канал вызывает панику, а чтение из закрытого и опустошённого канала возвращает ноль и `ok=false`. `omitempty` может удалить нулевое значение, которое новая версия хотела отличить от отсутствия.

Вопрос 5 из 25

В разделе «Чтение через io.Reader» показан конкретный случай. Какое замечание о цене решения будет точным?

Стандартный кодировщик надёжен для общего случая, но высоконагруженный путь нужно оптимизировать только после профиля. Преобразование в `[]rune` упрощает индексацию кодовых точек, но выделяет память и не решает задачу графем полностью. Теги удобны для простого контракта, но смешивание нескольких форматов в одной структуре делает модель хрупкой. Потоковый интерфейс экономит память, но требует аккуратного цикла и границ объёма для недоверенного входа. Карта даёт быстрый доступ по ключу, но для стабильного порядка ключи приходится собирать и сортировать отдельно.

Вопрос 6 из 25

В рабочем примере по теме «Запись через io.Writer» важно отделить гарантию от догадки. Что гарантированно произойдёт в показанной последовательности операций?

// Фрагмент для трассировки.
package main
import("bytes";"io")
func main(){ var b bytes.Buffer; n,err:=io.WriteString(&b,"go"); _,_=n,err }

Чтение `<-ch` получит `7` только после готовой отправки, а небуферизованный канал создаёт точку встречи. Старый потребитель проигнорирует новое поле при обычном декодировании, если не включён строгий запрет неизвестных полей. Для строки `"я"` значение `len(s)` равно 2 в UTF-8, а `utf8.RuneCountInString(s)` равно 1. Чтение `m["x"]` из `nil`-карты даёт `0`, но попытка `m["x"] = 1` завершится паникой. `io.WriteString` передаёт строку писателю и возвращает фактически записанное число байтов и ошибку.

Вопрос 7 из 25

Фрагмент относится к теме «Запись через io.Writer». Какой вариант исправления соответствует обычной практике Go?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import("bytes";"io")
func main(){ var b bytes.Buffer; n,err:=io.WriteString(&b,"go"); _,_=n,err }

Создавать карту через `make` или литерал до первой записи; чтение из `nil` допустимо, если такой контракт осознан. Проверять ошибку и заранее проектировать сериализуемую DTO без каналов, функций и циклических ссылок. Выбирать байтовую обработку для протоколов и `[]rune` или пакет `utf8` для операций над кодовыми точками. Проверять ошибку записи и использовать `io.Copy` для полного переноса потока с корректной обработкой коротких записей. Использовать `DisallowUnknownFields` на строгой внешней границе и ограничивать размер входного потока.

Вопрос 8 из 25

На ревью разбирают тему «Запись через io.Writer». Какой принцип языка объясняет результат полностью?

// Определите правило Go, которое объясняет результат.
package main
import("bytes";"io")
func main(){ var b bytes.Buffer; n,err:=io.WriteString(&b,"go"); _,_=n,err }

`Write(p)` сообщает число принятых байтов; `n < len(p)` без ошибки нарушает обычный контракт и трактуется как `io.ErrShortWrite` помощниками. `json.Decoder` читает последовательность значений из `io.Reader` и подходит для потока или большого документа. Строка — неизменяемая последовательность байтов; `len` возвращает число байтов, а не символов Unicode. Отправка и чтение синхронизируются согласно состоянию канала; операция с `nil`-каналом блокируется навсегда. `json.Marshal` возвращает байты и ошибку; неподдерживаемые значения вроде функций и каналов приводят к ошибке.

Вопрос 9 из 25

В разделе «Запись через io.Writer» показан конкретный случай. Какой предел контракта важен для вызывающего кода?

Одна видимая графема может состоять из нескольких рун, поэтому даже число рун не всегда равно числу пользовательских символов. Опция `omitempty` не всегда различает отсутствующее поле и переданное нулевое значение. `NaN` и бесконечности `float64` не являются допустимыми числами JSON и вызывают ошибку кодирования. Один успешный `Decode` не гарантирует отсутствие лишнего второго JSON-значения после ожидаемого объекта. Успех записи в буфер не означает, что данные уже синхронизированы с диском или доставлены по сети.

Вопрос 10 из 25

Команда проверяет решение по теме «Запись через io.Writer». Как решение скажется на тестировании и дальнейших изменениях?

Потоковый декодер снижает пиковую память, но строгая проверка окончания и схемы требует дополнительных шагов. Интерфейс `Writer` хорошо компонуется, но гарантии долговечности и подтверждения находятся на другом уровне. Преобразование в `[]rune` упрощает индексацию кодовых точек, но выделяет память и не решает задачу графем полностью. Карта даёт быстрый доступ по ключу, но для стабильного порядка ключи приходится собирать и сортировать отдельно. Стандартный кодировщик надёжен для общего случая, но высоконагруженный путь нужно оптимизировать только после профиля.

Вопрос 11 из 25

Фрагмент относится к теме «Композиция». Какое наблюдение о работе кода будет верным?

// Фрагмент для трассировки.
package main
import("bytes";"io";"strings")
func main(){ var copy bytes.Buffer; r:=io.TeeReader(strings.NewReader("abc"),&copy); _,_=io.ReadAll(r) }

`io.TeeReader` отдаёт данные вызывающему коду и одновременно записывает прочитанные байты в другой `Writer`. Чтение `m["x"]` из `nil`-карты даёт `0`, но попытка `m["x"] = 1` завершится паникой. Старый потребитель проигнорирует новое поле при обычном декодировании, если не включён строгий запрет неизвестных полей. Чтение `<-ch` получит `7` только после готовой отправки, а небуферизованный канал создаёт точку встречи. Два последовательных объекта могут быть декодированы двумя вызовами `Decode` без предварительного чтения всего входа.

Вопрос 12 из 25

На ревью разбирают тему «Композиция». Какую правку разумнее внести до объединения изменений?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import("bytes";"io";"strings")
func main(){ var copy bytes.Buffer; r:=io.TeeReader(strings.NewReader("abc"),&copy); _,_=io.ReadAll(r) }

Создавать карту через `make` или литерал до первой записи; чтение из `nil` допустимо, если такой контракт осознан. Сохранять смысл полей, добавлять версию там, где возможны несовместимые формы, и тестировать старые образцы. Задавать стабильные внешние имена тегами и отделять транспортную структуру от внутренней модели при разных требованиях. Комбинировать стандартные обёртки и закрывать ресурсы в порядке, соответствующем их контрактам. Проверять ошибку и заранее проектировать сериализуемую DTO без каналов, функций и циклических ссылок.

Вопрос 13 из 25

В разделе «Композиция» показан конкретный случай. Какое правило Go непосредственно объясняет поведение фрагмента?

// Определите правило Go, которое объясняет результат.
package main
import("bytes";"io";"strings")
func main(){ var copy bytes.Buffer; r:=io.TeeReader(strings.NewReader("abc"),&copy); _,_=io.ReadAll(r) }

Интерфейсы `Reader` и `Writer` позволяют связывать файлы, сеть, сжатие, хеширование и буферы без знания конкретных типов. Чтение отсутствующего ключа возвращает нулевое значение элемента; запись в `nil`-карту вызывает панику. Пакет `encoding/json` использует экспортированные поля и теги `json`; неэкспортированные поля не сериализуются. `json.Decoder` читает последовательность значений из `io.Reader` и подходит для потока или большого документа. Добавление необязательного поля обычно совместимо со старым JSON, а переименование или изменение смысла существующего поля требует миграции.

Вопрос 14 из 25

Команда проверяет решение по теме «Композиция». Где заканчивается гарантия показанного приёма?

`omitempty` может удалить нулевое значение, которое новая версия хотела отличить от отсутствия. Ошибка промежуточного писателя в `TeeReader` становится ошибкой чтения и останавливает поток. Отправка в закрытый канал вызывает панику, а чтение из закрытого и опустошённого канала возвращает ноль и `ok=false`. `NaN` и бесконечности `float64` не являются допустимыми числами JSON и вызывают ошибку кодирования. Один успешный `Decode` не гарантирует отсутствие лишнего второго JSON-значения после ожидаемого объекта.

Вопрос 15 из 25

Перед публикацией кода по теме «Композиция» нужно уточнить контракт. Когда этот приём помогает, а когда начинает мешать?

Стандартный кодировщик надёжен для общего случая, но высоконагруженный путь нужно оптимизировать только после профиля. Строгая схема быстрее ловит ошибки, но усложняет плавное добавление полей между независимо выпускаемыми системами. Потоковый декодер снижает пиковую память, но строгая проверка окончания и схемы требует дополнительных шагов. Композиция сокращает собственный код, но цепочка обёрток требует ясного владения закрытием и ошибками. Преобразование в `[]rune` упрощает индексацию кодовых точек, но выделяет память и не решает задачу графем полностью.

Вопрос 16 из 25

На ревью разбирают тему «Частичное чтение». Каков наблюдаемый результат этого кода?

// Фрагмент для трассировки.
package main
import("io";"strings")
func main(){ buf:=make([]byte,3); n,err:=io.ReadFull(strings.NewReader("ab"),buf); _,_=n,err }

Чтение `m["x"]` из `nil`-карты даёт `0`, но попытка `m["x"] = 1` завершится паникой. Чтение `<-ch` получит `7` только после готовой отправки, а небуферизованный канал создаёт точку встречи. При входе из двух байтов и буфере длины 3 `ReadFull` вернёт `n=2` и `io.ErrUnexpectedEOF`. Для строки `"я"` значение `len(s)` равно 2 в UTF-8, а `utf8.RuneCountInString(s)` равно 1. Два последовательных объекта могут быть декодированы двумя вызовами `Decode` без предварительного чтения всего входа.

Вопрос 17 из 25

В разделе «Частичное чтение» показан конкретный случай. Какое изменение лучше всего укрепит контракт этого фрагмента?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import("io";"strings")
func main(){ buf:=make([]byte,3); n,err:=io.ReadFull(strings.NewReader("ab"),buf); _,_=n,err }

Не оставлять канал `nil` случайно; намеренно использовать `nil` только для отключения ветви `select`. Использовать `DisallowUnknownFields` на строгой внешней границе и ограничивать размер входного потока. Проверять ошибку и заранее проектировать сериализуемую DTO без каналов, функций и циклических ссылок. Выбирать `ReadFull` для заголовков фиксированной длины и обычный цикл для произвольного потока. Выбирать байтовую обработку для протоколов и `[]rune` или пакет `utf8` для операций над кодовыми точками.

Вопрос 18 из 25

Команда проверяет решение по теме «Частичное чтение». Какое утверждение точнее всего описывает действующую гарантию?

// Определите правило Go, которое объясняет результат.
package main
import("io";"strings")
func main(){ buf:=make([]byte,3); n,err:=io.ReadFull(strings.NewReader("ab"),buf); _,_=n,err }

Для фиксированного блока `io.ReadFull` читает ровно нужное число байтов либо возвращает `ErrUnexpectedEOF`/`EOF`. Чтение отсутствующего ключа возвращает нулевое значение элемента; запись в `nil`-карту вызывает панику. `json.Decoder` читает последовательность значений из `io.Reader` и подходит для потока или большого документа. `json.Marshal` возвращает байты и ошибку; неподдерживаемые значения вроде функций и каналов приводят к ошибке. Строка — неизменяемая последовательность байтов; `len` возвращает число байтов, а не символов Unicode.

Вопрос 19 из 25

Перед публикацией кода по теме «Частичное чтение» нужно уточнить контракт. Что может изменить вывод при небольшом изменении условий?

`NaN` и бесконечности `float64` не являются допустимыми числами JSON и вызывают ошибку кодирования. Отправка в закрытый канал вызывает панику, а чтение из закрытого и опустошённого канала возвращает ноль и `ok=false`. Одна видимая графема может состоять из нескольких рун, поэтому даже число рун не всегда равно числу пользовательских символов. Опция `omitempty` не всегда различает отсутствующее поле и переданное нулевое значение. Даже при ошибке возвращённые `n` байтов могут быть полезны для диагностики, но недостаточны для полного сообщения.

Вопрос 20 из 25

В рабочем примере по теме «Частичное чтение» важно отделить гарантию от догадки. Как решение влияет на читаемость и надёжность?

Потоковый декодер снижает пиковую память, но строгая проверка окончания и схемы требует дополнительных шагов. Жёсткое чтение упрощает двоичный протокол, но требует ограничения размера до выделения памяти. Небуферизованный канал задаёт сильную координацию, но может ограничить пропускную способность и усилить взаимные ожидания. Строгая схема быстрее ловит ошибки, но усложняет плавное добавление полей между независимо выпускаемыми системами. Преобразование в `[]rune` упрощает индексацию кодовых точек, но выделяет память и не решает задачу графем полностью.

Вопрос 21 из 25

В разделе «Тестирование и наблюдаемость» показан конкретный случай в тесте «Интерфейсы io.Reader и io.Writer». Что увидит вызывающий код после выполнения?

// Фрагмент для трассировки.
package sample
import("io";"strings";"testing";"testing/iotest")
func TestRead(t *testing.T){ r:=iotest.OneByteReader(strings.NewReader("abc")); b,err:=io.ReadAll(r); if err!=nil||string(b)!="abc"{t.Fatal(string(b),err)} }

Таблица проверяет `int64` и собственный `Age`, поэтому ловит ошибочное сужение ограничения. Тест ошибки проверяет `errors.Is`, а не точное длинное сообщение с контекстом. Специальный `Reader` с одним байтом за вызов проверяет, что функция не рассчитывает на заполнение буфера сразу. Тест проверяет и значение, и `ok`, поэтому не путает нулевой элемент с закрытым каналом. Внешний тест не может обратиться к неэкспортированным полям и тем самым проверяет настоящий контракт пользователя.

Вопрос 22 из 25

Команда проверяет решение по теме «Тестирование и наблюдаемость» в тесте «Интерфейсы io.Reader и io.Writer». Как подготовить этот код к реальному использованию?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package sample
import("io";"strings";"testing";"testing/iotest")
func TestRead(t *testing.T){ r:=iotest.OneByteReader(strings.NewReader("abc")); b,err:=io.ReadAll(r); if err!=nil||string(b)!="abc"{t.Fatal(string(b),err)} }

Инъецировать часы или длительности в код с большим числом временных сценариев, чтобы тесты не зависели от реального ожидания. Использовать `iotest` и собственные маленькие заглушки, измерять число байтов и длительность без записи содержимого секретных потоков. Использовать барьеры вместо сна, запускать `-race` и отслеживать число горутин до и после серии операций. Добавлять нагрузочные тесты, `-race` и снимки горутин при зависании; число сообщений в очереди использовать только как метрику. Записывать метод, хост, статус, длительность и категорию ошибки, не превращая URL с идентификаторами в метки высокой кардинальности.

Вопрос 23 из 25

Перед публикацией кода по теме «Тестирование и наблюдаемость» нужно уточнить контракт в тесте «Интерфейсы io.Reader и io.Writer». Какой контракт определяет результат показанного кода?

// Определите правило Go, которое объясняет результат.
package sample
import("io";"strings";"testing";"testing/iotest")
func TestRead(t *testing.T){ r:=iotest.OneByteReader(strings.NewReader("abc")); b,err:=io.ReadAll(r); if err!=nil||string(b)!="abc"{t.Fatal(string(b),err)} }

Потоковый код тестируют читателями, которые дробят данные, возвращают ошибки после байтов и выполняют короткие записи. Слой данных тестируют на ошибках начала, запроса, сканирования и коммита; отдельно нужен интеграционный тест реальной базы. Протокол канала тестируют на обычном пути, закрытии, отмене и отсутствии потребителя; зависание ограничивают таймаутом теста. Перед выпуском нужны модульные, интеграционные и нагрузочные проверки критических путей, а после — контролируемое наблюдение новых ошибок и задержки. Обобщённый алгоритм тестируют представителями разных ветвей ограничения и именованными типами, а не только `int`.

Вопрос 24 из 25

В рабочем примере по теме «Тестирование и наблюдаемость» важно отделить гарантию от догадки в тесте «Интерфейсы io.Reader и io.Writer». Какое допущение здесь чаще всего оказывается ложным?

Слишком короткий таймаут делает тест нестабильным на медленной машине, а отсутствие таймаута способно повесить весь набор. Тест только с `bytes.Buffer` слишком дружелюбен и может не выявить ошибочную обработку частичного чтения. Тест только успешного 200 не проверяет закрытие тела, медленные заголовки, разрыв соединения и повтор. Большой запас уменьшает нестабильность, но маскирует медленную работу; слишком малый порог ломается под нагрузкой среды. Тест только конечного тела не обнаружит двойной вызов `next` или потерю `Flusher`.

Вопрос 25 из 25

Фрагмент относится к теме «Тестирование и наблюдаемость» в тесте «Интерфейсы io.Reader и io.Writer». Какое замечание о цене решения будет точным?

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