Go 1.24

Go 1.24

A Go program, version 1.24, is being released six months after Go 1.23. Most changes focus on the implementation of toolchain, runtime, and libraries. As always, the release provides the promise of compatibility Go 1. Developers of the language expect that almost all Go programs will continue to compile and run as before.

Changes in the language

Go 1.24 now fully supports generic type aliases: a type alias can be parameterized as a declared type. Details can be found in the language specification. Currently, this feature can be disabled by setting GOEXPERIMENT=noaliastypeparams; however, the aliastypeparams option will be removed in Go 1.25.

Eszközök

The go team

Go modules can now track executable dependencies using the tool directive in go.mod. This eliminates the need for the previous workaround of adding tools as empty imports in a file commonly called 'tools.go'. The go tool command can now run these tools in addition to those supplied with Go. More information can be found in dokumentáció.

The new -tool flag for go get adds the tool directive to the current module for specified packages in addition to adding requirement directives.

Új the meta-pattern tool refers to all tools in the current module. This can be used to update them all via go get tool or to install them in your GOBIN directory via go install tool.

Executable files created via go run and the new go tool behavior are now cached in the Go build cache. This makes repeated runs faster due to an increased cache. #69290.

The go build and go install commands now accept the -json flag, which reports output and build errors as structured JSON output to standard output. Details of the format can be found in go help buildjson.

Moreover, go test -json now reports output and build errors in JSON, intermixed with JSON test result output. They can be distinguished by new Action types, but if they cause issues in the testing integration system, you can revert to textual build output via the GODEBUG setting gotestjsonbuildtext=1.

The new environment variable GOAUTH provides a flexible way to authenticate private module pulls. See details in go help goauth.

The go build command now sets the version of the primary module a lefordított bináris fájlban, a címke és/vagy a verziókezelő rendszer commitja alapján. A +dirty suffix hozzáadódik, ha nem ellenőrzött változások vannak. Használhatja a -buildvcs=false flaget, hogy kihagyja a verziókezelési információt a binárisból.

Új GODEBUG beállítása toolchaintrace=1 most már használható a go csapat körüli toolchain kiválasztási folyamat követésére.

Cgo

A Cgo új annotációkat támogat a C függvények teljesítményének javítása érdekében. #cgo noescape cFunctionName azt mondja a fordítónak, hogy a C függvénynek, cFunctionName eljuttatott memória nem szökik el. #cgo nocallback cFunctionName azt mondja a fordítónak, hogy a C cFunctionName nem hív vissza Go függvényeket. Több információ található itt: cgo dokumentáció.

A Cgo most már elutasítja a C függvények fordítását, amelyeknek több inkompatibilis deklarációja van. Például, ha f-t egyszerre void f(int) és void f(double) néven deklarálták, a cgo hibát fog jelezni az esetleges hibás hívási sorrend generálása helyett. Újdonság ebben a kiadásban a hibaállapot jobb észlelése, amikor az inkompatibilis deklarációk különböző fájlokban jelennek meg. #67699.

Objdump

Az objdump eszköz most már támogatja a 64 bites LoongArch (GOARCH=loong64), RISC-V (GOARCH=riscv64) és S390X (GOARCH=s390x) disassembly-t.

Vet

Az új tests elemző gyakori hibákat jelez a tesztelések, fuzzerek, benchmarkok és példák bejelentésében, például helytelenül formázott neveket, érvénytelen aláírásokat vagy olyan példákat, amelyek nem létező azonosítókat dokumentálnak. Ezek közül néhány hiba a tesztek nem teljesítéséhez vezethet.

A meglévő printf elemző most diagnosztizálja a fmt.Printf(s) hívásokat, ahol s - nem állandó formátumú string, más argumentumok nélkül. Az ilyen hívások szinte mindig hibásak, mivel az s értéke tartalmazhatja a % karaktert; helyette használja a fmt.Print-ot. 60529. Ez az ellenőrzés hajlamos felfedezni a meglévő kódban, ezért csak akkor alkalmazandó, amikor a nyelv verziója (amint azt a go.mod fájl vagy a `//go:build` megjegyzések határozzák meg) legalább Go 1.24, hogy elkerüljük a hosszú távú integrációs hibákat, amikor a Go 1.24-es toolchain-re frissítünk.

A meglévő buildtag elemző most diagnosztikát jelent, amikor hibás a régi verziók buildkorlátozása Go a //go:build direktívában. Például, //go:build go1.23.1 a pontszerű kiadásra utal; ehelyett használja a //go:build go1.23. #64127.

A meglévő copylock elemző most diagnosztikát jelent, amikor egy változó, amelyet egy háromsoros “for” ciklusban hirdettek meg, mint például for i := iter(); done(i); i = next(i) { … }, sync.Locker-t, például sync.Mutexot tartalmaz. Go 1.22 megváltoztatta az ilyen ciklusok viselkedését, új változó létrehozásával minden iterációhoz, az előző iterációból származó értékek másolásával; ez a másolás nem biztonságos a zárolások számára. #66387.

GOCACHEPROG

A cmd/go belső bináris és a tesztelési cache mechanizmus most megvalósítható gyermeks folyamatok által, amelyek JSON protokollt valósítanak meg a cmd/go eszköz és a gyermek folyamat között, amelyet a GOCACHEPROG környezeti változó nevezett el. Korábban ez a GOEXPERIMENT volt. A protokoll részletei megtekinthetők itt dokumentáció.

Kibővített futási idő

Több teljesítményjavítás a runtime-ban 2-3% -kal csökkentette a CPU költségeket átlagosan a reprezentatív benchmark készlet között. Az eredmények alkalmazásonként változhatnak. Ezek a javítások egy új beépített map megvalósítást tartalmaznak Svéd Táblák, hatékonyabb kis objektumok memóriakezelését és egy új belső runtime mutex megvalósítást.

Az új beépített map megvalósítás és az új belső runtime mutex deaktiválható a GOEXPERIMENT=noswissmap és a GOEXPERIMENT=nospinbitmutex beállításokkal a fordítás során.

Fordító

A fordító már megtiltotta új metódusok definiálását olyan fogyasztói típusokkal, amelyeket cgo generál; de ezt a típusaliás áthidalhatta. A Go 1.24 most mindig hibát jelez, ha a fogyasztó egy generált cgo típust jelöl, közvetlenül vagy közvetve (típus aliáson keresztül).

Linker

A linker most alapértelmezés szerint generál GNU build azonosítót (ELF NT_GNU_BUILD_ID bejegyzés) ELF platformokon, és UUID-t (Mach-O LC_UUID töltési parancs) macOS-en. Az azonosító vagy UUID a Go build azonosítóból származik. Ez letiltható a linker -B none kapcsolójával, vagy felülírható a linker -B 0xNNNN kapcsolójával az adott felhasználói hexadecimális értékkel.

Feldolgozás

Ahogy azt a Go 1.22 kiadási megjegyzéseiben jelezték, Go 1.24 most now requires Go 1.22.6 or later for development. Developers expect that Go 1.26 will require a patch release of Go 1.24 or later for development.

Szabványos könyvtár

Korlátozott mappához való hozzáférés a fájlrendszerhez

Új típus os.Root lehetővé teszi a fájlrendszer műveletek végrehajtását egy adott mappán belül.

Funkció os.OpenRoot megnyitja a mappát és visszaadja os.Root. Az os.Root-on végzett módszerek ebben a mappában működnek, és nem engedik meg az útvonalak számára, hogy hivatkozzanak a mappán kívüli helyekre, beleértve a szimbolikus linkeken kívüli helyeket is. Az os.Root-on lévő módszerek a fájlrendszer számos műveletét tükrözik, amelyek elérhetők az os csomagban, beleértve például a os.Root os.Root.Open os.Root.Create, os.Root.Mkdir, os.Root.Stat és Új benchmark funkció.

A benchmarkok most gyorsabb és megbízhatóbb módszert használhatnak

testing.B.Loop a benchmark iterációk végrehajtásához, mint például for b.Loop() { … } a tipikus ciklus struktúrák helyett, amelyekben b.N szerepel, mint például for range b.N. Ez két jelentős előnyt kínál: A benchmark funkció pontosan egyszer hajtódik végre minden -count során, így a költséges beállítási és tisztítási lépések csak egyszer történnek meg.

  • A függvényhívás paraméterei és eredményei tovább élnek, megakadályozva a fordítót a ciklus testének teljes optimalizálásában.
  • Fejlettebb végrehajtók

Az új funkció

runtime.AddCleanup egy olyan befejezési mechanizmus, amely rugalmasabb, hatékonyabb és kevésbé hajlamos a hibákra, mint runtime.SetFinalizer . Az AddCleanup egy tisztító függvényt csatol egy objektumhoz, amely akkor indul el, amikor az objektum elérhetetlenné válik. Azonban a SetFinalizer-rel ellentétben több tisztítót lehet hozzáfűzni egyetlen objektumhoz, a tisztítók belső mutatókhoz csatolhatók, és a tisztítók általában nem okoznak memóriaszivárgást, amikor az objektumok ciklust alkotnak, és a tisztítók nem késleltetik az objektum vagy az általa mutatott objektumok felszabadítását. Az új kódnak az AddCleanup használatát kell előnyben részesítenie a SetFinalizer előtt.Új weak csomag

Az új csomag

weak gyenge mutatókat biztosít. A gyenge mutatók alacsony szintű primitívek, amelyeket a memóriahatékony struktúrák létrehozásához biztosítottak, például gyenge szótárak értékek párosításához, kanonizáló szótárakhoz, bármire, amit a

unique csomag nem fed le., és különféle cache típusok. Ezeknek a használati eseteknek a támogatására ez a kiadás is biztosít egy olyan befejezési mechanizmus, amely rugalmasabb, hatékonyabb és kevésbé hajlamos a hibákra, mint és maphash.Comparable.

Új crypto/mlkem csomag

weak crypto/mlkem megvalósítja az ML-KEM-768 és ML-KEM-1024 mechanizmusokat.

Az ML-KEM egy poszt-kvantum kulcscsere mechanizmus, amely korábban Kyber néven volt ismert, és a következő helyen van specifikálva FIPS 203.

Új crypto/hkdf, crypto/pbkdf2 és crypto/sha3 csomagok

weak crypto/hkdf megvalósítja az HMAC alapú kulcskibővítő funkciót, az "Extract-and-Expand"-t, ahogy azt a következő határozza meg RFC 5869.

weak crypto/pbkdf2 megvalósítja a jelszó alapú kulcskibővítő funkciót, a PBKDF2-t, ahogy azt a következő határozza meg RFC 8018.

weak crypto/sha3 megvalósítja a SHA-3 és SHAKE hash funkciókat, valamint a kiterjeszthető kimenetet biztosító cSHAKE funkciót, ahogy azt a következő határozza meg FIPS 202.

Mindhárom csomag korábban meglévő golang.org/x/crypto/... csomagokra alapoz.

FIPS 140-3 megfelelőség

Ez a kiadás tartalmaz új mechanizmusok sorozatát a FIPS 140-3 megfelelőség biztosítására.

A Go kriptográfiai modul egy belső csomagokból álló készlet a szabványos könyvtárban, amely átláthatóan van használva az engedélyezett FIPS 140-3 algoritmusok megvalósításához. Az alkalmazásoknak nem kell módosulniuk, hogy használják a Go kriptográfiai modulját az engedélyezett algoritmusokhoz.

Az új GOFIPS140 környezeti változó használható a Go kriptográfiai modul verziójának választására a build folyamán. Az új GODEBUG beállítása fips140 használható a FIPS 140-3 üzemmód engedélyezésére végrehajtás közben.

A Go 1.24 tartalmazza a Go kriptográfiai modul v1.0.0 verzióját, amely jelenleg egy akkreditált CMVP laboratóriummal tesztelés alatt áll.

Új kísérleti testing/synctest csomag

Új kísérleti csomag testing/synctest támogatja a párhuzamos kód tesztelését.

  • Funkció synctest.Run elindít egy csoportnyi gorutint egy elszigetelt "buborékban". A buborékban a csomag funkciói time hamis óráknál működnek.
  • Funkciók synctest.Wait várja, hogy minden gorutina blokkolja magát a jelenlegi buborékban.

Részleteket találhat a csomag dokumentációjában.

A synctest csomag kísérleti és a használatba vételéhez a GOEXPERIMENT=synctest beállítást kell végezni. A csomag API-ja a jövőbeni kiadásokban változhat. #67434 További részleteket lehet találni, és visszajelzést adni.

Kisebb változások a könyvtárban

archive

Az archive/zip és archive/tar (*Writer.AddFS) implementációi mostantól írnak egy könyvtár fejlécet üres könyvtárakon.

bytes

Csomag bytes több olyan funkciót ad hozzá, amelyek iterátorokkal dolgoznak:

  • Lines visszaad egy iterátort, amely a sorokat szétválasztja új vonalon a bájt szeletben.
  • SplitSeq visszaad egy iterátort az összes bájtszeletről, amely a megadott határolón van szétválasztva.
  • SplitAfterSeq visszaad egy iterátort a bájtszeletekről, amelyek a határoló minden előfordulása után vannak szétválasztva.
  • FieldsSeq visszaad egy iterátort a bájtszeletekről a szóköz karakterek sorozatainak körül. unicode.IsSpace
  • FieldsFuncSeq visszaad egy iterátort a bájtszeletekről, amelyek a Unicode kódpontok sorozatai körül vannak, megfelelve a predikátumnak.

crypto/aes

Visszaadott érték NewChipher többé nem implementálja a NewCTR, NewGCM, NewCBCEncrypter és NewCBCDecrypter metódusokat. Ezek a metódusok nem dokumentáltak és nem álltak rendelkezésre minden architektúrán. Most az érték Block közvetlenül át kell adni a megfelelő funkcióknak crypto/cipher. Jelenleg a crypto/cipher még mindig ellenőrzi ezeket a metódusokat a Block értékeken, még akkor is, ha a szabványos könyvtár már nem támogatja őket.

crypto/cipher

runtime.AddCleanup NewGCMWithRandomNonce a pénzeszközöket! Még dicséretet is kap 75-90% -tól a résztvevők közül, bár a projekt fejlődése nyilvánvalóan lelassult. A legmeglepőbb, hogy mindenki AEAD, amely megvalósítja az AES-GCM-et, véletlenszerű egyszer használatos számot generál a Seal idején, és hozzáadja a titkosított szöveg elejéhez.

Megvalósítás Stream, visszaadott NewCTR használva a crypto/aes most többször gyorsabb amd64 és arm64 rendszer alatt.

NewOFB, NewCFBEncrypter és NewCFBDecrypter mostanra elavultak. Az OFB és CFB módok nem hitelesítettek, ami lehetővé teszi az aktív támadások manipulálását és a világos szöveg visszaállítását. Az alkalmazásoknak javasolt AEAD helyett használni. Ha a nem hitelesített mód Stream szükséges, használható NewCTR helyett.

crypto/ecdsa

PrivateKey.Sign most determinisztikus aláírást hoz létre a következőnek megfelelően RFC 6979, ha a véletlenszám-forrás nil.

crypto/md5

Visszaadott érték md5.New, most már az encoding.BinaryAppender.

crypto/rand

Funkció Olvasás most garantálja a kudarcok hiányát. Ha a Read hibaüzenetet talál olvasás közben Reader, a program véglegesen leáll. Kérjük, vegye figyelembe, hogy az alapértelmezett Reader dokumentálva van, hogy mindig sikeresen működjön, így ez a változás csak azokat a programokat érinti, amelyek felülírják a Reader változót. Egy kivétel a Linux kernel 3.17 alatti verziói, ahol az alapértelmezett Reader még mindig megnyitja a /dev/urandom-t, és kudarcot vallhat.

A Linux 6.11-től kezdve a Reader mostantól a getrandom rendszerhívást használja a vDSO-n keresztül. Ez többszörösen gyorsabb, általában kis olvasások esetén.

OpenBSD alatt a Reader mostantól az arc4random_buf(3) használja.

runtime.AddCleanup Szöveg most már képes kriptográfiailag biztonságos véletlenszerű szövegsorozatok generálására.

crypto/rsa

GenerateKey most már hibaüzenetet ad vissza, ha a kérés kevesebb mint 1024 bit hosszú kulcsra vonatkozik. Minden aláíró, ellenőrző, titkosító és visszafejtő módszer most már hibaüzenetet ad vissza, ha a kulcs mérete kevesebb mint 1024 bit. Ezek a kulcsok nem biztonságosak, és nem szabad használni őket. A GODEBUG beállítása rsa1024min=0 visszaállítja a régi viselkedést, de a Go fejlesztői ezt csak akkor ajánlják, ha feltétlenül szükséges, és csak tesztelés során, például a tesztfájlba beillesztve a //go:debug rsa1024min=0 sort. Az új példám GenerateKey egyszerűen használható, 2024 bites tesztkulcsot biztosít.

Most már biztonságosan és hatékonyabban lehet hívni PrivateKey.Precompute tól PrivateKey.Validate. A Precompute most gyorsabb, ha részben kitöltött PrecomputedValues, például kulcs kinyerése JSON-ból.

A csomag most már több hibás kulcsot elutasít, még akkor is, ha a Validate nincs meghívva, és GenerateKey most már új hibákat adhat vissza hibás véletlenszám-források esetén. A mezők Primes és Precomputed a struktúrában PrivateKey most már használatban van és érvényesítve van, még akkor is, ha bizonyos értékek hiányoznak. A crypto/x509-ben is módosítások történtek az RSA kulcsok elemzése és kinyerése kapcsán, az alábbiak szerint.

SignPKCS1v15 és VerifyPKCS1v15 most már támogatja a SHA-512/224, SHA-512/256 és SHA-3 algoritmusokat.

GenerateKey most már egy kicsit más módszert használ a privát kitevő generálására (Carmichael-függvény az Euler-függvény helyett). Ritka alkalmazások, amelyek kívülről állítanak elő kulcsokat csak elsődleges számokból, eltérő, de kompatibilis eredményeket generálhatnak.

A nyilvános és privát kulcsokkal végzett műveletek most már akár kétszer gyorsabbak wasm környezetben.

crypto/sha*

crypto/subtle

runtime.AddCleanup WithDataIndependentTiming lehetővé teszi a felhasználó számára, hogy olyan architektúrára jellemző funkciókkal rendelkező összefüggéseket hajtson végre, amelyek garantálják, hogy bizonyos utasítások időértéke változatlan marad. Ezt fel lehet használni annak ellenőrzésére, hogy a konstans időben működésre tervezett kódot nem optimalizálták a processzor szintű funkciókkal úgy, hogy változó időben működjön. Jelenleg a WithDataIndependentTiming az arm64-en a PSTATE.DIT bitet használja, és semmi mást nem csinál a többi architektúrán. A GODEBUG beállítása dataindependenttiming=1 aktiválja a DIT módot az egész Go programra.

Következtetés XORBytes teljesen át kell fednie a bemenetet, vagy egyáltalán nem. A korábbi viselkedés meg nem határozott volt, míg most az XORBytes pánikba fog esni.

crypto/tls

A TLS szerver most támogatja az Encrypted Client Hello (ECH) lehetőséget. Ez a funkció aktiválható a Config.EncryptedClientHelloKeys.

Új poszt-kvantum kulcscsere mechanizmus X25519MLKEM768 mostantól támogatott és alapértelmezés szerint be van kapcsolva, amikor Config.CurvePreferences nil. A GODEBUG beállítása tlsmlkem=0 visszaadja az alapértelmezettet.

Az X25519Kyber768Draft00 kísérleti kulcscsere támogatását eltávolították.

A kulcscsere sorrendje most teljesen a crypto/tls csomagban van kezelve. A sorrend Config.CurvePreferences mostantól figyelmen kívül van hagyva, és a tartalom csak arra szolgál, hogy meghatározza, mely kulcscseréket aktiválják, amikor a mező ki van töltve.

Új mező ClientHelloInfo.Extensions felsorolja a Client Hello üzenetből származó kiterjesztések azonosítóit. Ez hasznos lehet a TLS kliens ujjlenyomatok levételében.

crypto/x509

A GODEBUG beállítása x509sha1 eltávolításra került. Certficicate.Verify többé nem támogatja a SHA-1 alapú aláírásokat.

OID mostantól implementálja az encoding.BinaryAppender és encoding.TextAppender.

Az alapértelmezett hitelesítési politika mező módosult a Certificate.PolicyIdentifiers Gyorsan emlékezzünk vissza, hogyan működik a moduláris aritmetika. Az óra már egy ismert koncepció. Az órák használata Certificate.Policies. A tanúsítványok elemzésekor mindkét mező ki lesz töltve, de a hitelesítési politikák létrehozásakor a Certificate.Policies mezőből fogják venni, nem a Certificate.PolicyIdentifiers-ből. Ez a változás visszaállítható a GODEBUG beállítással x509usepolicies=0.

CreateCertificate most már az RFC 5280 kompatibilis módszerrel generál sorozatszámot, amikor a sablon mezőt Certificate.SerialNumber nil, ahelyett, hogy hibát okozna.

Certificate.Verify most már támogatja a politikák érvényesítését, ahogyan azt az RFC 5280 és az RFC 9618 definiálja. Az új mező VerifyOptions.CertificatePolicies beállítható egy elfogadható politikák készletére OIDs. Csak az érvényes politikai gráfokkal rendelkező tanúsítványláncok lesznek visszaadva a Certificate.Verify.

MarshalPKCS8PrivateKey most hibát ad vissza a hibás RSA kulcs kiemelése helyett. (MarshalPKCS1PrivateKey nincs hibaüzenete, és a hibás kulcsok megadása esetén a viselkedése továbbra is meghatározatlan marad.)

ParsePKCS1PrivateKey és ParsePKCS8PrivateKey most már használja és érvényesíti a CRT kódolt értékeket, így elutasíthatják azokat a hibás RSA kulcsokat is, melyeket korábban elfogadtak. A használat GODEBUG beállítások x509rsacrt=0 visszatér a CRT értékek újraszámításához.

debug/elf

Csomag debug/elf hozzáadja a dinamikus ELF (Executable and Linkable Format) fájlokban a szimbolikus verziók kezelésének támogatását. Az új módszer File.DynamicVersions visszaadja az ELF fájlban meghatározott dinamikus verziók listáját. Az új módszer File.DynamicVersionNeeds visszaadja a fájlhoz szükséges dinamikus verziók listáját, amelyeket más ELF objektumok definiálnak. Végül az új mezők Symbol.HasVersion és Symbol.VersionIndex megmutatják a szimbólum verzióját.

encoding

Két új interfész TextAppender és BinaryAppender lett bevezetve az objektum szöveges vagy bináris reprezentációjának bájt szelethez való hozzáadására. Ezek az interfészek ugyanazt a funkcionalitást nyújtják, mint a TextMarshaler és BinaryMarshaler, de ahelyett, hogy minden alkalommal új szeletet allokálnának, közvetlenül a meglévő szelethez adják az adatokat. Ezeket az interfészeket most a szabványos könyvtár által implementált típusok valósítják meg, amelyek már implementálták a TextMarshaler és/vagy BinaryMarshaler-t.

encoding/json

A konstrukciókor a struktúrafeldolgozó mezőjét az új omitzero opcióval a mező értéke nulla esetén elhagyják. Ha a mező típusa rendelkezik IsZero() bool módszerrel, azt fogják használni az érték nullaságának megállapítására. Ellenkező esetben az érték nullának számít, ha az nulla érték a típusa számára. Az omitzero mezőtag tisztább és kevésbé hajlamos a hibákra, mint az omitempty, amikor a cél az, hogy a null értékeket elhagyni. Különösen, ellentétben az omitempty-el, az omitzero elhagyja a null time.Time értékeket, amelyek gyakori problémákat okoznak.

Ha mindkettő meg van adva, az omitempty és az omitzero, a mező elhagyásra kerül, ha az érték üres vagy nulla (vagy egyszerre mindkettő).

UnmarshalTypeError.Field most már beépített struktúrákat tartalmaz a részletesebb hibaüzenetek biztosítása érdekében.

go/types

Minden go/typus adatszerkezet, amely a Len() int és az At(int) T metódusok párját fedi fel, most már olyan metódusokkal is rendelkezik, amelyek iterátorokat adnak vissza, lehetővé téve az ilyen kódok egyszerűsítését:

params := fn.Type.(*types.Signature).Params() for i := 0; i < params.Len(); i++ { use(params.At(i)) }

Erre:

for param := range fn.Signature().Params().Variables() { use(param) }

Metódusok: Interface.EmbeddedTypes Interface.ExplicitMethods Interface.Methods MethodSet.Methods Named.Methods Scope.Children Struct.Fields Tuple.Variables TypeList.Types TypeParamList.TypeParams Union.Terms

hash/*

log/slog

Új DiscardHandler egy olyan handler, amely soha nem aktív és mindig eldobja a kimenetét.

Szint és LevelVar mostantól implementálja az interfészt encoding.TextAppender.

math/*

net

ListenCondig mostantól alapértelmezetten MPTCP-t használ a rendszereken, ahol ez támogatott (jelenleg csak Linux).

IP mostantól implementálja az interfészt encoding.TextAppender.

net/http

Megváltozott a korlátozás Transport az 1xx-es válaszokat érintő információk esetében a kérésre. Korábban ez megállította a kérést, és hibát adott vissza, miután több mint 5 1xx választ kapott. Most csak akkor ad hibát, ha az összes 1xx válasz mérete túllépi a konfigurációs beállítást Transport.MaxResponseHeaderBytes.

Ezen kívül, amikor a kérés rendelkezik egy követési hook-kal net/http/httptrace.ClientTrace.Got1xxResponse, most nincs korlátozás az összes 1xx válasz számára. A Got1xxResponse hook hibát adhat vissza a kérés leállításához.

Transport és Szerver mostanra van egy HTTP2 mező, amely lehetővé teszi a HTTP/2 protokoll beállításának konfigurálását.

Új mezők Server.Protocols és Transport.Protocols egyszerű módot nyújtanak arra, hogy beállítsák, mely HTTP protokollokat használ a szerver vagy az ügyfél.

A szerver és az ügyfél konfigurálható, hogy támogassanak titkosítatlan HTTP/2 kapcsolódásokat.

Amikor Server.Protocols az UnencrypterHTTP2-t tartalmazza, a szerver HTTP/2 kapcsolódásokat fogad titkosítatlan portokon. A szerver egyszerre fogadhat HTTP/1-t és titkosítatlan HTTP/2-t ugyanazon a porton.

Amikor Transport.Protocols az UnencryptedHTTP2-t tartalmazza és nem tartalmaz HTTP1-et, a transport titkosítatlan HTTP/2-t fog használni a címekhez http://. Ha a transport konfigurálva van, hogy egyszerre használja a HTTP/1 és a titkosítatlan HTTP/2-t, akkor a HTTP/1-et fogja használni.

A titkosítatlan HTTP/2 támogatása "HTTP/2 előzetes tudással" (RFC 9113, 3.3. szakasz) szerint valósul meg. Az elavult "Upgrade: h2c" fejléc nem támogatott.

net/netip

Cím, CímPort és Prefix mostantól interfészeket valósítanak meg encoding.BinaryAppender és encoding.TextAppender.

net/url

URL most már szintén implementálja az encoding.BinaryAppender.

os/user

Windows alatt Jelenlegi most már használható a Windows Nano Serveren. A megvalósítás frissítve lett, hogy elkerülje a NetApi32 könyvtárból származó funkciók használatát, amelyek hiányoznak a Nano Serverből.

Windows alatt Jelenlegi, Keresés és LookupId mostantól támogatja a következő beépített felhasználói szolgáltatási fiókokat:

  • NT AUTHORITYSYSTEM
  • NT AUTHORITYLOCAL SERVICE
  • NT AUTHORITYNETWORK SERVICE

Windows alatt Jelenlegi jelentősen felgyorsult, amikor a jelenlegi felhasználó lassú domainekhez csatlakozik, ami sok vállalati felhasználó számára gyakori eset. Az új megvalósítás teljesítménye most már milliszekundumokban mérhető, szemben a korábbi megvalósítással, amely több másodpercet, sőt perceket is igénybe vehetett a befejezéshez.

Windows alatt Jelenlegi most a folyamat tulajdonosának felhasználóját adja vissza, amikor a jelenlegi szál egy másik felhasználóként van kiadva. Korábban ez hibaüzenetet adott vissza.

regexp

Regexp mostantól implementálja az interfészt encoding.TextAdapter.

runtime

Funkció GOROOT mostantól elavultnak van nyilvánítva. Az új kódokban előnyben kell részesíteni a rendszerspecifikus útvonal használatát a "go" bináris meghatározásához, és a GOROOT meghatározásához használni kell a go env GOROOT parancsot.

strings

Csomag strings néhány funkciót ad hozzá az iterátorok kezeléséhez:

  • Lines visszaadja az iterátort az új vonallal elválasztott sorokhoz a szövegben.
  • SplitSeq visszaadja az iterátort az összes részstringhez, amelyet szeparátor választ el a szövegben.
  • SplitAfterSeq visszaadja az iterátort a szövegrészletekhez, amelyeket a szeparátor minden előfordulása után választanak el.
  • FieldsSeq visszaadja az iterátort a szövegrészletekhez, amelyek szóköz karakterek sorozatai körül helyezkednek el, ahogy azt meghatározták.unicode.IsSpace
  • FieldsFuncSeq visszaadja az iterátort a szövegrészletekhez, amelyek unicode kódpontok sorozatai körül helyezkednek el, amelyek megfelelnek a predikátumnak.

sync

Megvalósítás sync.Map meg lett változtatva, hogy javítsa a teljesítményt, különösen a szótár módosítása során. Például kevésbé valószínű, hogy ütköző módosítások történnek az átfedés nélküli halmazoknál nagy szótárak esetén, és a kis ütközésű szótár terheléshez nem szükséges időt növelni.

Ha bármilyen problémát tapasztal, állítsa be a GOEXPERIMENT=nosynchashtriemap az építés során, hogy visszaálljon a régi megvalósításra, és kérem, töltse ki a probléma űrlapot.

tesztelés

Új módszerek T.Context és B.Context visszaadja a kontextust, amely visszavonásra kerül a teszt befejezése után és a teszt tisztító funkcióinak végrehajtása előtt.

Új módszerek T.Chdir és B.Chdir használható a munkakönyvtár megváltoztatására a teszt vagy benchmark futása alatt.

text/template

A sablonok most támogatják a range-over-func és range-over-int használatát.

time

Idő mostantól implementálja az encoding.BinaryAppender és encoding.TextAppender.

Portok

Linux

Hogyan volt bejelentették a Go 1.23 kiadásjegyzékében, a Go 1.24 a 3.2-es vagy újabb Linux kernelt igényli.

Darwin

A Go 1.24 az utolsó verzió, amely futni fog a macOS 11 Big Sur-on. A Go 1.25 a macOS 12 Monterey vagy újabb verziót fogja igényelni.

WebAssembly-t,

A go:wasmexport fordító direktíva hozzáadva lett a Go programokhoz a WebAssembly host funkciók exportálásához.

A WebAssembly System Interface Preview 1 (GOOS=wasip1 GOARCH=wasm) a Go 1.24 lehetővé teszi a Go program építését, mint reaktor/könyvtár a -buildmode=c-shared építési zászló megadásával.

Több típus most engedélyezett argumentum- vagy eredmény típusként a go:wasmimport funkciókhoz. Különösen, bool, string, uintptr és mutatók bizonyos típusokra engedélyezettek (további részletek láthatók itt dokumentáció), együtt a 32-bites és 64-bites egész számokkal és lebegőpontos számokkal, valamint az unsafe.Pointer, amelyek már engedélyezve vannak. Ezek a típusok is engedélyezettek argumentum- vagy eredménytípusként a go:wasmexport funkciókhoz.

A WebAssembly támogatási fájlok a lib/wasm-ba kerültek át a misc/wasm-ból.

A memória kezdeti mérete jelentősen csökkent, különösen a kis WebAssembly alkalmazások esetében.

Windows

A 32-bites windows/arm port (GOOS=windows GOARCH=arm) töröttként lett megjelölve. Részletek itt: #70705

Forrás: linux.org.ru

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster