JSON, файлы и сериализация — бесплатный тест онлайн

Вопрос 1 из 25

В рабочем примере по теме «Теги struct» важно отделить гарантию от догадки. К какому результату приводит показанная конструкция?

// Фрагмент для трассировки.
package main
import("encoding/json")
type Item struct{ Name string `json:"name"`; secret string `json:"secret"` }
func main(){ _,_=json.Marshal(Item{Name:"Go",secret:"x"}) }

Чтение `m["x"]` из `nil`-карты даёт `0`, но попытка `m["x"] = 1` завершится паникой. Чтение `<-ch` получит `7` только после готовой отправки, а небуферизованный канал создаёт точку встречи. Результат содержит `{"name":"Go"}`, а поле `secret` отсутствует независимо от тега, потому что оно не экспортировано. `io.TeeReader` отдаёт данные вызывающему коду и одновременно записывает прочитанные байты в другой `Writer`. Код сначала обрабатывает `n` байтов, а затем завершает цикл по `io.EOF`, не теряя последний фрагмент.

Вопрос 2 из 25

Фрагмент относится к теме «Теги struct». Какую правку стоит предложить на ревью, сохранив назначение кода?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import("encoding/json")
type Item struct{ Name string `json:"name"`; secret string `json:"secret"` }
func main(){ _,_=json.Marshal(Item{Name:"Go",secret:"x"}) }

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

Вопрос 3 из 25

На ревью разбирают тему «Теги struct». На какой контракт языка или стандартной библиотеки здесь нужно опереться?

// Определите правило Go, которое объясняет результат.
package main
import("encoding/json")
type Item struct{ Name string `json:"name"`; secret string `json:"secret"` }
func main(){ _,_=json.Marshal(Item{Name:"Go",secret:"x"}) }

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

Вопрос 4 из 25

В разделе «Теги struct» показан конкретный случай. Какое ограничение опаснее всего пропустить?

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

Вопрос 5 из 25

Команда проверяет решение по теме «Теги struct». Какой вывод о сопровождении решения наиболее взвешенный?

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

Вопрос 6 из 25

Фрагмент относится к теме «Кодирование JSON». Как завершится показанный фрагмент при указанных входных данных?

// Фрагмент для трассировки.
package main
import "encoding/json"
func main(){ _,err:=json.Marshal(map[string]any{"f":func(){}}); _=err }

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

Вопрос 7 из 25

На ревью разбирают тему «Кодирование JSON». Что здесь следует изменить прежде всего?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "encoding/json"
func main(){ _,err:=json.Marshal(map[string]any{"f":func(){}}); _=err }

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

Вопрос 8 из 25

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

// Определите правило Go, которое объясняет результат.
package main
import "encoding/json"
func main(){ _,err:=json.Marshal(map[string]any{"f":func(){}}); _=err }

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

Вопрос 9 из 25

Команда проверяет решение по теме «Кодирование JSON». Какой крайний случай обязан попасть в тесты?

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

Вопрос 10 из 25

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

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

Вопрос 11 из 25

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

// Фрагмент для трассировки.
package main
import("encoding/json";"strings")
func main(){ dec:=json.NewDecoder(strings.NewReader(`{"n":1} {"n":2}`)); var a,b map[string]int; _=dec.Decode(&a); _=dec.Decode(&b) }

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

Вопрос 12 из 25

В разделе «Потоковый декодер» показан конкретный случай. Какое замечание на ревью будет наиболее точным?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import("encoding/json";"strings")
func main(){ dec:=json.NewDecoder(strings.NewReader(`{"n":1} {"n":2}`)); var a,b map[string]int; _=dec.Decode(&a); _=dec.Decode(&b) }

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

Вопрос 13 из 25

Команда проверяет решение по теме «Потоковый декодер». Какое правило важнее случайных деталей конкретного запуска?

// Определите правило Go, которое объясняет результат.
package main
import("encoding/json";"strings")
func main(){ dec:=json.NewDecoder(strings.NewReader(`{"n":1} {"n":2}`)); var a,b map[string]int; _=dec.Decode(&a); _=dec.Decode(&b) }

`json.Decoder` читает последовательность значений из `io.Reader` и подходит для потока или большого документа. Строка — неизменяемая последовательность байтов; `len` возвращает число байтов, а не символов Unicode. Для фиксированного блока `io.ReadFull` читает ровно нужное число байтов либо возвращает `ErrUnexpectedEOF`/`EOF`. Интерфейсы `Reader` и `Writer` позволяют связывать файлы, сеть, сжатие, хеширование и буферы без знания конкретных типов. `Read(p)` возвращает число прочитанных байтов и ошибку; допустимо получить `n>0` вместе с `io.EOF`.

Вопрос 14 из 25

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

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

Вопрос 15 из 25

В рабочем примере по теме «Потоковый декодер» важно отделить гарантию от догадки. Что учитывать при выборе этого приёма для публичного API?

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

Вопрос 16 из 25

В разделе «Версионирование данных» показан конкретный случай. Какой результат даст этот код на поддерживаемой реализации Go?

// Фрагмент для трассировки.
package main
type V2 struct{ Version int `json:"version"`; Name string `json:"name"`; Note string `json:"note,omitempty"` }
func main(){}

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

Вопрос 17 из 25

Команда проверяет решение по теме «Версионирование данных». Что нужно поменять, чтобы граничный случай не превратился в сбой?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
type V2 struct{ Version int `json:"version"`; Name string `json:"name"`; Note string `json:"note,omitempty"` }
func main(){}

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

Вопрос 18 из 25

Перед публикацией кода по теме «Версионирование данных» нужно уточнить контракт. Какое свойство конструкции определяет её поведение?

// Определите правило Go, которое объясняет результат.
package main
type V2 struct{ Version int `json:"version"`; Name string `json:"name"`; Note string `json:"note,omitempty"` }
func main(){}

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

Вопрос 19 из 25

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

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

Вопрос 20 из 25

Фрагмент относится к теме «Версионирование данных». Как точнее всего описать пользу и цену этого решения?

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

Вопрос 21 из 25

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

// Фрагмент для трассировки.
package sample
import("os";"path/filepath";"testing")
func TestFile(t *testing.T){ p:=filepath.Join(t.TempDir(),"x.json"); if err:=os.WriteFile(p,[]byte(`{"n":1}`),0600);err!=nil{t.Fatal(err)} }

Тест отменяет контекст после первого результата и убеждается, что выход закрывается за ограниченное время. Подменный транспорт возвращает контролируемый ответ без реального внешнего соединения. Тест считается успешным только если вызов действительно вызвал ожидаемую панику; отсутствие паники — отдельная ошибка теста. Внешний тест не может обратиться к неэкспортированным полям и тем самым проверяет настоящий контракт пользователя. `t.TempDir()` создаёт изолированный каталог и автоматически удаляет его после теста.

Вопрос 22 из 25

Перед публикацией кода по теме «Тестирование и наблюдаемость» нужно уточнить контракт. Какую правку стоит предложить на ревью, сохранив назначение кода?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package sample
import("os";"path/filepath";"testing")
func TestFile(t *testing.T){ p:=filepath.Join(t.TempDir(),"x.json"); if err:=os.WriteFile(p,[]byte(`{"n":1}`),0600);err!=nil{t.Fatal(err)} }

Запускать `-shuffle`, `-count`, `-race`, хранить медленные интеграционные тесты отдельно и анализировать пропуски покрытия по риску. Выносить проверку паники в небольшую функцию и добавлять `debug.Stack()` в журнал на эксплуатационной границе. Хранить репрезентативные старые документы в `testdata`, проверять ограничения размера и не журналировать полный чувствительный JSON. Проверять заголовки, контекст, статус, паники и дополнительные интерфейсы ResponseWriter. Хранить примеры компилируемыми, тестировать нулевое значение и конкурентный контракт, если они обещаны.

Вопрос 23 из 25

В рабочем примере по теме «Тестирование и наблюдаемость» важно отделить гарантию от догадки. На какой контракт языка или стандартной библиотеки здесь нужно опереться?

// Определите правило Go, которое объясняет результат.
package sample
import("os";"path/filepath";"testing")
func TestFile(t *testing.T){ p:=filepath.Join(t.TempDir(),"x.json"); if err:=os.WriteFile(p,[]byte(`{"n":1}`),0600);err!=nil{t.Fatal(err)} }

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

Вопрос 24 из 25

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

Тест только с `bytes.Buffer` слишком дружелюбен и может не выявить ошибочную обработку частичного чтения. Круговой тест может скрыть одинаковую ошибку кодировщика и декодировщика, поэтому нужен независимый ожидаемый внешний вид. Высокое покрытие может состоять из тестов без содержательных утверждений. Тесты только внутри пакета могут случайно зависеть от деталей, недоступных реальному пользователю. Тест только успешного 200 не проверяет закрытие тела, медленные заголовки, разрыв соединения и повтор.

Вопрос 25 из 25

На ревью разбирают тему «Тестирование и наблюдаемость». Какой вывод о сопровождении решения наиболее взвешенный?

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