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

Строки в Python неизменяемы, поэтому конкатенация обычно создаёт новую строку и копирует в неё прежнее содержимое. При последовательном добавлении множества фрагментов суммарное число копируемых символов может расти как квадрат итогового размера; для сборки результата обычно используют str.join или потоковый буфер.

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

Неизменяемость строк упрощает их совместное использование, хеширование и безопасную передачу между частями программы. Обратная сторона такого подхода — изменение строки нельзя выполнить непосредственно: операция должна создать новое значение, сохранив старое неизменным.

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

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

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

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

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

str.join получает последовательность фрагментов, определяет необходимый итоговый размер и формирует результат как единую строку. При этом ранее собранный префикс не копируется заново на каждой итерации, поэтому для общего объёма текста размером N работа близка к O(N).

parts = []
for record in records:
    parts.append(format_record(record))

result = "".join(parts)

Здесь список хранит ссылки на фрагменты, а не копии их символов. Компромисс состоит в дополнительной памяти для списка и самих промежуточных строк; если фрагменты уже поступают как готовая коллекция, отдельное накопление может быть не нужно.

Для очень больших потоков текста альтернативой служит io.StringIO: он позволяет постепенно записывать данные во внутренний буфер и получить итоговую строку в конце. Это не означает, что любая операция += обязательно будет квадратичной: CPython иногда оптимизирует конкатенацию локальной строки, когда у неё нет других ссылок. Однако такое поведение не является надёжной общей гарантией языка и может исчезнуть при наличии алиасов, другой структуры кода или другой реализации Python.

Если результат нужен как байты, применяют соответствующий буфер или bytearray, а не смешивают строковые и байтовые операции. Выбор инструмента должен учитывать не только скорость, но и необходимость получить единую строку, объём доступной памяти и возможность потоковой отправки результата без полной материализации.

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

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

Рассматривались три варианта:

заменить цикл на накопление строк и join: обычно это простой и быстрый вариант, но он всё равно требует хранить все фрагменты и итоговую строку;
использовать StringIO: сохраняет потоковую модель записи и обычно уменьшает повторное копирование, но итоговая строка всё равно будет создана при вызове getvalue;
сразу передавать строки в сетевой поток: минимизирует пиковую память, но усложняет обработку ошибок, настройку буферизации и повторную отправку ответа.

Если API требовал целиком сформированный ответ, был выбран join при умеренном размере данных. Для больших ответов выбрали потоковую запись через StringIO либо отправку порциями, потому что оптимизация времени одной конкатенации не устраняет необходимость хранить весь итоговый документ.

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

Всегда ли += для строк в цикле имеет квадратичную сложность?

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

Устраняет ли join все дополнительные расходы памяти?

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

Когда StringIO предпочтительнее join?

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