개요
Go는 Google이 개발한 정적 타입 컴파일 언어로, 간결함, 높은 동시성(goroutine과 channel) 및 빠른 컴파일로 유명합니다. 표준 라이브러리는 네트워크, 암호화 및 Web 서버를 다루며, 현대적인 클라우드 및 시스템 소프트웨어에 적합합니다.
README 미리보기
# The Go Programming Language\n\nGo is an open source programming language that makes it easy to build simple,\nreliable, and efficient software.\n\n\n*Gopher image by [Renee French][rf], licensed under [Creative Commons 4.0 Attribution license][cc4-by].*\n\nOur canonical Git repository is located at https://go.googlesource.com/go.\nThere is a mirror of the repository at https://github.com/golang/go.\n\nUnless otherwise noted, the Go source files are distributed under the\nBSD-style license found in the LICENSE file.\n\n### Download and Install\n\n#### Binary Distributions\n\nOfficial binary distributions are available at https://go.dev/dl/.\n\nAfter downloading a binary release, visit https://go.dev/doc/install\nfor installation instructions.\n\n#### Install From Source\n\nIf a binary distribution is not available for your combination of\noperating system and architecture, visit\nhttps://go.dev/doc/install/source\nfor source installation instructions.\n\n### Contributing\n\nGo is the work of thousands of contributors. We appreciate your help!\n\nTo contribute, please read the contribution guidelines at https://go.dev/doc/contribute.\n\nNote that the Go project uses the issue tracker for bug reports and\nproposals only. See https://go.dev/wiki/Questions for a list of\nplaces to ask questions about the Go language.\n\n[rf]: https://reneefrench.blogspot.com/\n[cc4-by]: https://creativecommons.org/licenses/by/4.0/\n
FAQ (5)
문제 해결code actions 사용 시 canRemoveParameter에서 발생하는 gopls panic을 수정하는 방법
이것은 gopls v0.14.0의 알려진 버그입니다: 'remove unused parameter' 리팩터링(refactorRewrite)이 함수 매개변수가 본문이 없는 외부 함수에 속해 있을 때 nil 포인터 역참조로 인해 패닉을 일으킵니다. 이는 canRemoveParameter가 nil 본문에 대해 go/ast.Inspect를 호출하기 때문입니다. 해당 수정은 CL 537878에 반영되었으며 0.14 릴리스 브랜치로 백포트되었습니다. 이 문제를 해결하려면 gopls를 v0.14.1 이상으로 업그레이드하세요: go install golang.org/x/tools/gopls@latest, 그런 다음 에디터/언어 서버를 다시 시작하세요.
문제 해결windows/386에서 VirtualQuery를 사용할 때 windows.MemoryBasicInformation이 잘못된 RegionSize, State, Protect, Type 값을 반환하는 이유는 무엇인가요?
golang.org/x/sys/windows의 MemoryBasicInformation이 windows/386에서 잘못된 구조체 레이아웃을 가지고 있었습니다: 잘못 추가된 PartitionId 필드(CL 352249에서 추가됨)로 인해 AllocationProtect 이후의 모든 필드가 4바이트씩 밀렸고, 그 결과 VirtualQuery/VirtualQueryEx가 정렬이 어긋난 값을 반환했으며 Type은 전혀 기록되지 않았습니다. 해결 방법은 golang.org/x/sys를 CL 849405가 포함된 버전으로 업그레이드하는 것입니다. 해당 CL은 windows/386에서 PartitionId 필드를 제거하여 구조체가 네이티브 32비트 MEMORY_BASIC_INFORMATION ABI와 일치하도록 합니다:
go get golang.org/x/sys@latest
go mod tidy코드가 386에서 MemoryBasicInformation.PartitionId를 참조하는 경우, 업그레이드 후 해당 사용 부분을 제거하세요(더 이상 컴파일되지 않습니다). 이 제거는 의도적으로 소스 호환성을 깨는 변경이라는 점에 유의하세요. 잘못된 레이아웃을 유지하면 이후의 모든 필드가 잘못된 오프셋에 계속 남아 있기 때문입니다.
문제 해결Go 1.28에서 net.IPMask.MarshalText가 오류 없이 빈 출력을 반환하는 이유는 무엇인가요?
이것은 GODEBUG=netmarshal=1을 통해 새로운 텍스트 마샬링 형식이 활성화되었을 때 Go 1.28-devel에서 발생하는 버그입니다. 길이가 0, 4 또는 16바이트가 아닌 IPMask의 경우, MarshalText가 nil 에러와 함께 빈 바이트를 조용히 반환하여 데이터가 손실됩니다(예: json.Marshal이 ""를 생성하고 언마샬링하면 빈 마스크가 됩니다). 원인은 src/net/ip.go에 있으며, addr, _ := netip.AddrFromSlice(m)가 ok 결과를 버리기 때문에 제로 Addr이 빈 출력을 생성합니다. 해결 방법: (1) GODEBUG=netmarshal=0으로 새 형식을 비활성화하여 이전 base64 인코딩으로 폴백합니다. 이 인코딩은 모든 마스크 길이를 올바르게 라운드트립합니다. (2) 유효한 길이(0, 4 또는 16바이트)의 마스크만 마샬링합니다. 예를 들어 마샬링하기 전에 netip.AddrFromSlice로 검증하고 ok 결과를 확인합니다. 이 수정 사항(유효하지 않은 마스크 길이에 대해 nil이 아닌 에러를 반환)은 Go 1.28의 릴리스 블로커로 표시되어 있습니다.
문제 해결linux/arm64에서 TestMulHighSVE SIGSEGV 크래시를 해결하는 방법 (SVE 결과 벡터가 인접한 스택 슬롯을 덮어씀)?
이것은 cmd/compile의 SVE 레지스터 인수 morestack 스필 오프셋 버그이며, 이미 CL 828585(2026-10-02에 머지됨)를 통해 Go master에서 수정되었습니다. 이 크래시는 arm64 memmove FP/SIMD 변경(CL 840906) 때문에 발생한 것이 아닙니다. LUCI는 업로드된 그대로의 패치셋 커밋을 빌드하는데, 이 CL의 모든 패치셋이 수정 이전인 2026-09-28 시점의 master(a696473376)를 기반으로 하고 있었기 때문에 trybot에서 문제가 나타난 것입니다. 수정/우회 방법: CL을 현재 master(2026-10-02 이후의 커밋이면 됨)로 리베이스한 후 다시 업로드하여 trybot 실행에 컴파일러 수정이 포함되도록 하세요. 증상 확인: 스필된 SVE(Z 레지스터) 인수가 morestack 호출 중 잘못된 스택 오프셋에 기록되어 인접 슬롯(예: sp+0x88의 클로저 포인터가 MulHigh 결과 레인으로 덮어씌워짐)을 손상시키며, 이로 인해 'unexpected fault address 0xffffffbb00000777'과 같은 폴트가 발생합니다.
문제 해결GODEBUG=netmarshal=1 설정에서 net.HardwareAddr에 대해 json.Marshal이 성공한 후 json.Unmarshal이 "invalid MAC address" 오류와 함께 실패하는 이유는 무엇인가요?
이것은 Go 표준 라이브러리 버그입니다(golang/go#82360). GODEBUG=netmarshal=1이 설정된 경우, net.HardwareAddr.MarshalText는 HardwareAddr.String()을 사용하며, 이는 임의의 길이를 가진 바이트 슬라이스를 16진수 형식으로 포맷합니다. 반면 UnmarshalText는 ParseMAC을 사용하며, 이는 6, 8 또는 20바이트 주소만 허용합니다. 따라서 {0x01, 0x02, 0x03}과 같은 HardwareAddr은 "01:02:03"으로 마샬링되지만 address 01:02:03: invalid MAC address 오류로 언마샬링에 실패합니다. 수정/우회 방법: (1) CL 851265(net: marshal and unmarshal invalid HardwareAddr values)가 포함된 Go 버전으로 업그레이드하면 마샬/언마샬이 유효하지 않은 길이를 처리합니다; (2) GODEBUG=netmarshal=1을 제거하여 이전의 base64 JSON 인코딩으로 되돌리면 모든 슬라이스 길이에 대해 라운드트립이 가능합니다; (3) 텍스트 마샬링 동작이 필요한 경우 표준 MAC 길이(6, 8 또는 20바이트)만 사용하십시오.