Ответ.

В языке Go организация кода через пакеты (packages) и систему видимости играет ключевую роль в модульности, повторном использовании и инкапсуляции логики.

История вопроса

В отличие от многих классических языков с объектно-ориентированным наследованием, Go с нуля задумывался вокруг простых модулей — пакетов с четкими правилами экспорта и импортов. Это наследие философии минимализма, простоты и строгого контроля зависимостей.

Проблема

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

Решение

В Go каждый файл обязательно принадлежит какому-либо пакету (package имя). Вся область видимости в Go определяется:

Начинаться с заглавной буквы (экспортируемый/public)
Начинаться со строчной (приватный/private)

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

Пример структуры:

project/
│
├── main.go          // package main
└── mathutil/
    └── mathutil.go  // package mathutil

Пример кода:

// mathutil/mathutil.go
package mathutil

// Public - экспортируемая функция
func Sum(a, b int) int {
    return a + b
}

// private - неэкспортируемая функция
func subtract(a, b int) int {
    return a - b
}

// main.go
package main

import (
    "fmt"
    "project/mathutil"
)

func main() {
    fmt.Println(mathutil.Sum(2, 3))      // 5
    // fmt.Println(mathutil.subtract(3,2)) // Ошибка компиляции! subtract неэкспортируемая
}

Ключевые особенности:

Простая и прозрачная модель экспорта/импортов
Экспорт определяется только первой буквой имени — никакие ключевые слова не требуются
Каждый каталог реализует ровно один пакет

Вопросы с подвохом.

Можно ли экспортировать переменную или функцию, объявленную с маленькой буквы, при помощи других механизмов?

Нет. В Go нет ключевых слов вроде public, private, все определяется только первой буквой имени (unicode category — заглавная буква).

Могут ли функции из одного файла пакета использовать приватные функции из другого файла того же пакета?

Да, область видимости ограничена на уровне пакета, а не файла. Все приватные элементы доступны во всех файлах одного пакета.

Пример кода:

// mathutil/helpers.go
package mathutil

func hiddenHelper() int { return 42 }

// mathutil/mathutil.go
package mathutil

func UseHelper() int {
    return hiddenHelper() // доступно!
}

Можно ли создать одну и ту же функцию или тип с одинаковым именем внутри одного пакета в разных файлах?

Нет, будет ошибка компиляции — внутри пакета имена должны быть уникальными, даже если объявлены в разных файлах.

Типовые ошибки и анти-паттерны

Случайно экспортировать детали реализации, начав имя с большой буквы
Дробить пакеты на файлы с одинаковыми именами типов
Класть слишком много логики в пакет main (нарушение модульности)
Использовать export только ради тестирования (лучше использовать файл xxx_test.go в том же пакете)

Пример из жизни

Негативный кейс

Большая команда кладет все вспомогательные функции и типы в пакет util с экспортом всего подряд:

Плюсы:

Быстро использовать любые функции без разбора

Минусы:

Потеря инкапсуляции (детали реализации легко становятся зависимостью других пакетов)
Сложность рефакторинга и тестирования

Позитивный кейс

Команда тщательно делит код по модулям по бизнес-областям, экспортирует только API: