Знакомство с excelize: зачем Go работает с Excel

Excelize — библиотека на чистом Go, которая умеет создавать, читать и изменять xlsx-файлы, а заодно xlsm с макросами и шаблоны xltm и xltx. Чистый Go здесь ключевое слово: никаких обёрток над Excel, вызовов через COM-объекты или запуска LibreOffice на сервере — один пакет, один импорт, работает на Linux в контейнере так же, как на ноутбуке. Проект развивается с 2016 года, вырос из внутренней разработки компании 360 и давно стал де-факто стандартом работы с xlsx в экосистеме Go: если видите в Go-проекте зависимость для Excel-файлов, с высокой вероятностью это excelize. Внутри — работа с формулами, стилями, диаграммами, картинками, условным форматированием и закреплением областей, плюс потоковые API для файлов на миллионы строк, куда обычный режим уже не влезает по памяти. Для нас это значит простую вещь: почти любая задача из мира таблиц уже имеет готовую функцию с документацией и примером, и весь курс мы будем именно их разбирать.

Современный xlsx — это не бинарный формат, а zip-архив с набором XML-документов внутри, стандартизованный как Office Open XML (ECMA-376). Переименуйте любой xlsx в zip и распакуйте — увидите знакомую картину: описание книги в xl/workbook.xml, каждый лист отдельным документом в xl/worksheets, общая таблица строк в xl/sharedStrings.xml, стили в xl/styles.xml, плюс служебные части вроде [Content_Types].xml и свойств документа в docProps. Из этого следуют практические вещи. Файл можно инспектировать руками: когда что-то идёт не так, заглянуть в XML честнее, чем гадать по поведению Excel. Строки и стили хранятся отдельно от ячеек: одна и та же строка текста встречается в sharedStrings один раз, а ячейки на неё ссылаются. И числа хранятся как числа: то, что вы видите как дату, внутри — серийный номер дня, а внешность задаёт числовой формат; к этому мы вернёмся в уроках про стили и форматы, а пока достаточно общего понимания карты.

Зачем Go работает с Excel — честнее отвечать задачами, которые приносят деньги. Первая и самая частая — отчёты: сервис по расписанию собирает данные из базы и складывает в файл с вкладками по периодам, который утром ждёт бухгалтерия; такой экспорт из базы мы соберём в уроке про экспорт отчёта из базы в Excel. Вторая — обмен с внешним миром: поставщики присылают прайсы в xlsx, банки — выписки, подрядчики — графики работ, и их надо разобрать в структуры Go; отдельный урок про импорт таблицы в структуры. Третья — интеграции с учётными системами: 1С и её родственники понимают xlsx лучше, чем REST API. Четвёртая — генерация документов с заполненным шаблоном: акты, накладные, спецификации. Пятая — разовые миграции: перенести данные из таблиц в систему или обратно. Заметьте закономерность: везде данные уже есть, вопрос только в форме, в которой их примет другой участник процесса — чаще всего человек с Excel на другом конце.

API excelize построен вокруг дескриптора *File — объекта, с которым вы работаете от создания до сохранения. excelize.NewFile возвращает книгу в памяти: все SetCellValue и прочие изменения живут только там, и никакой report.xlsx на диске не появится, пока вы не вызовете SaveAs. Для существующего файла есть симметричная пара — OpenFile, который читает xlsx и возвращает тот же дескриптор; дальше разницы нет, читаете вы или пишете. У дескриптора есть метод Close, и это не формальность: при открытии файла excelize распаковывает архив во временную папку, чтобы не держать всё в памяти, и Close прибирает за собой — забытый вызов оставляет мусор во временных каталогах, что особенно обидно для генератора отчётов, работающего по расписанию месяцами. Привычка из этого урока: defer f.Close() сразу после создания или открытия, ошибки сохранения — проверять, а не игнорировать. Методов у дескриптора много, но они комбинируются однообразно: лист, координата, значение — эта триада проходит через весь курс.

Самый частый вопрос на старте: зачем целая библиотека, если CSV пишется fmt-ом за десять минут? Ответ в том, что CSV — не Excel. В нём нет листов, стилей, числовых форматов и формул; запятая внутри значения ломает файл, а Excel при открытии сам решает, что считать числом, — и немецкая локаль с запятой-разделителем превращает 12.5 в дату или текст. CSV остаётся отличным форматом обмена между программами, но как только файл будут открывать люди, нужен xlsx. Из Go-библиотек конкурент excelize — старый пакет tealeg/xlsx — жив, но развивается медленнее и по API громоздче. Ещё один путь — командовать установленным LibreOffice или Excel через командную строку и скрипты: работает, но тащит на сервер целый офис с лицензионными и операционными заботами.

Спорное мнение, которое я защищаю на проектировании: если файл нужен машине, а не человеку — берите CSV, а excelize оставьте для людей. Обмен между вашими же сервисами через CSV с фиксированными заголовками дешевле в отладке: дифф виден глазами, файл грузится в любой инструмент, а знание о типах лежит в схеме, а не в ячейках. Excelize включается, когда появляется человек, который открывает результат двойным кликом и ожидает вкладки, итоговые строки и внятные форматы чисел. Граница простая: файл живёт в пайплайнах между вашими сервисами — CSV; результат открывает директор — xlsx. Что excelize не умеет, тоже честно: старый бинарный формат Excel 97-2003 (.xls) не читается и не пишется — только современный OOXML; в PDF ничего не рендерится — печать остаётся заботе Excel; и формулы библиотека не вычисляет, она хранит выражение, а значение Excel считает при открытии, поэтому из только что сгенерированного файла формула вернёт не число, а её текстовое представление.