Wejście (schemat .proto)

Wyjście (Go)

Co robi to narzędzie

Go jest natywnym językiem protobufa — większość produkcyjnych usług gRPC jest napisana właśnie w nim. Zwykle generujesz Go z .proto używając protoc-gen-go albo buf, co oznacza zainstalowanie toolchaina, skonfigurowanie generatora i odpalenie kroku build. Ten konwerter wykonuje to samo w twojej przeglądarce — wklej, skopiuj, wrzuć do repo.

Mapowanie typów idzie za tym, co generuje protoc-gen-go: string → string, bool → bool, bytes → []byte, typy całkowite mapują się na swoje odpowiedniki int32/int64/uint32/uint64 (bez utraty precyzji jak w JavaScripcie), double → float64, float → float32. Pojedyncze pola wiadomości to wskaźniki (zgodnie z konwencją oficjalnych bindingów Go dla protobufa), repeated T staje się []T, map<K, V> staje się map[K]V.

Nazwy pól dostają kanoniczne dla Go potraktowanie PascalCase, z popularnymi akronimami w wielkich literach (order_id → OrderID, api_url → APIURL) zgodnie ze stylem review Go. Każde pole otrzymuje gotowe do wklejenia tagi struct: protobuf:"varint,3,opt,name=status,proto3" dla formatu wire i json:"status,omitempty" dla marshallingu JSON. Konwersja jest lokalna — twój .proto nigdy nie opuszcza przeglądarki. W kodzie produkcyjnym i tak będziesz musiał odpalić prawdziwy codegen, żeby dostać metody, deskryptory i obsługę reflection — ale do szkiców, review i jednorazowych skryptów to jest szybsze.

Jak tego używać

Trzy kroki. Wyjście to gotowy do wklejenia kod Go, który kompiluje się tak jak jest z biblioteką standardową.

Wklej swój schemat .proto

Wrzuć schemat do edytora po lewej. syntax = "proto3"; u góry jest OK, ale opcjonalne. Parser obsługuje zagnieżdżone bloki message, deklaracje enum, oneof, map<K, V> i opcje pól. Importy są rozpoznawane, ale pomijane.

Nazwy pól automatycznie konwertują się ze snake_case na PascalCase. Konwerter zamienia popularne sufiksy akronimowe na wielkie litery (Id → ID, Url → URL), żeby wynik przeszedł revive / golint bez narzekania.

Przeczytaj wynik

Po prawej: Go z jednym type X struct na wiadomość i blokiem type X int32 + const na każdy enum. package proto u góry to placeholder — zmień go na prawdziwą nazwę swojego pakietu.

Wepnij to do projektu

Wrzuć plik do projektu, popraw deklarację package i zaimportuj. Dla prawdziwego kodu gRPC i tak będziesz chciał odpalić protoc-gen-go, żeby dostać metody marshal/unmarshal. To wyjście jest pomyślane do typowanej obsługi JSON, szkiców struct i review — metody wire format protobufa nie są tu generowane.

Kiedy to faktycznie oszczędza czas

Szkicowanie usługi Go z istniejącego .proto

Stawiasz usługę Go, która konsumuje wiadomości Protobuf od innego zespołu. Chcesz mieć kształty struct dla sygnatur handlerów i odpowiedzi JSON bez stawiania pełnego pipeline'u codegen. Wklej, wrzuć do types.go i masz typy.

Review zmiany API Protobuf dla konsumenta Go

Backendowy kolega dodał pola do wiadomości. Wklej nowy .proto, zrób diff wyjścia Go względem swojego obecnego types.go, zostaw konkretną review. Szybsze niż odpalanie toolchaina tylko po to, żeby spojrzeć na zmianę.

Sanity check między językami

Masz .proto konsumowany zarówno przez klientów Go, jak i TypeScript. Użyj tego obok konwertera Protobuf do TypeScript, żeby potwierdzić, że oba języki zobaczą po kodowaniu JSON kompatybilne nazwy pól i typy.

Jednorazowe skrypty integracyjne

Piszesz pięćdziesięciolinijkowy skrypt Go uderzający w endpoint gRPC-gateway. Stawianie protoc, buf i konfigu generatora dla jednego skryptu to przesada. Wygeneruj struct tutaj, wrzuć je do skryptu, wypchnij.

Częste pytania

Czy to zastępuje protoc-gen-go?

Nie. protoc-gen-go generuje binarne metody marshal/unmarshal, deskryptory plików i obsługę reflection potrzebną do prawdziwego gRPC. Ten konwerter generuje tylko kształty struct i tagi. Jeśli piszesz prawdziwą usługę gRPC, odpal oficjalny codegen. Jeśli potrzebujesz tylko typów do odpowiedzi JSON, ręcznie pisanych skryptów albo szkiców — to jest szybsze.

Dlaczego pola typu wiadomość są wskaźnikami?

Odzwierciedla to, co protoc-gen-go robi z polami wiadomości w proto3 — są wskaźnikami, więc zero value to nil (odróżnialne od obecnej, ale pustej wiadomości). Pola skalarne zostają wartościami, bo ich zero values są same w sobie poprawne (pusty string, 0, false). Jeśli z jakiegoś powodu wolisz nie-wskaźniki, zrób find-replace na gwiazdkach w wyjściu.

Jak generowane są enumy?

Jako Go-we typedefy int32 z blokiem const, zgodnie z konwencjami protoc-gen-go. Każda wartość enum staje się stałą Go w PascalCase tego typu. Numeryczne przypisania pochodzą wprost z .proto.

A co z tagami struct protobuf?

Każde pole otrzymuje tag protobuf:"..." z wire type (varint, fixed32, fixed64, bytes), numerem pola, etykietą (opt/rep), nazwą i markerem proto3. Plus tag json:"name,omitempty" używający oryginalnej nazwy snake_case. Tagi map<K, V> są uproszczone — dla ścisłej zgodności z wire format odpal prawdziwy codegen.

Jak konwertowane są nazwy pól?

snake_case → PascalCase, z popularnymi sufiksami akronimowymi w wielkich literach: order_id → OrderID, api_url → APIURL, data_json → DataJSON. Pasuje to do konwencji review Go, więc wynik przechodzi lint bez ręcznego sprzątania.

Co jeśli mój schemat importuje inny .proto?

Instrukcje import są rozpoznawane i pomijane — typy wiadomości międzyplikowych renderują się ich liściastą nazwą (foo.Bar → Bar), której Go nie rozwiąże, dopóki ten typ nie istnieje też w tym samym pakiecie. Albo wkleisz importowane wiadomości inline, albo zakładasz, że poprawisz odniesienia w wyjściu.

Powiązane narzędzia

Jeśli pracujesz z Protobufem, JSON-em i Go, te dobrze ze sobą współgrają:

Konwerter Protobuf do Go