Previously, the biggest problem with using TinyGo was the memory leak issue. For detailed information, please refer to this issue: tetratelabs#450 (comment).

As I understand it, the core reasons for memory leaks when using TinyGo are as follows: When using conservative garbage collection (GC), misjudgments may occur when the value ranges of pointers and ordinary data overlap. As a result, some memory that is no longer in use cannot be reclaimed correctly, leading to continuous memory growth. When using precise GC, such as bdwgc, precise GC requires the compiler to provide accurate object layout and pointer information to accurately determine which are pointers and which are ordinary data. However, the TinyGo compiler only fills in information for precise GC in some cases.

As I understand it, switching to native Go can solve this problem. May I ask if you or the upstream Go community have any relevant verification cases in this regard for reference?

After preliminary verification, the response time of using Go 1.24 is slightly higher than that of TinyGo, and the size of the compiled WASM file is a bit larger. But in fact, for most users, stability is more important. The memory leak problem of TinyGo has been plaguing most users.