Every slice points to a backing array. The Go garbage collector does not look at the active slices. It only looks at the pointers that exist in allocated memory, which would be the entire array even if you only have an active slice to one element of it.
Anyway, yes a slice contains a reference/pointer which keeps an entire backing array alive during GC.
If you are keeping that backing array for a long period of time, and that array contains pointers or slices, then yes you need to set them to nil.
In my experience with services written in Go you can do a lot better by deciding how much RAM you want to use and allocate fixed size arrays. Perhaps you decide 100 MB is a good amount and so you allocate 80 MB in a fixed size array made up of fixed size structs. And any request that overflows that is rejected. Or if your request slots are full delay handling it until the early requests complete.
Or instead of an array of structs have each handler goroutine allocate a persistent fixed size struct to use as it receives each request over its channel. Then you start a fixed number of goroutine handlers at service start.
Anyway ... garbage collection is your enemy. And it won't run if you don't allocate memory. So just allocate one time up front, avoid excess memory allocation and then you don't have weird GC pauses and GC consuming your CPU time. Don't go overboard avoiding it, but large arrays of nested pointers that escape function scope are a really bad idea.