Is creating a goroutine per request (e.g., in net/http) a good design? What are the risks?

Yes. net/http runs one goroutine per connection, and each request on that connection is handled in that goroutine (HTTP/2 uses one goroutine per stream). This works because goroutines are cheap and the netpoller parks idle connections without holding threads. The code stays sequential and easy to read.

Risks to discuss:

• No built-in backpressure. A traffic spike creates unlimited goroutines and memory use. Mitigate with ReadTimeout, WriteTimeout and IdleTimeout, MaxHeaderBytes, netutil.LimitListener, load shedding, or a concurrency-limiting middleware.
• Goroutines started from handlers outlive the request unless they are tied to r.Context(). For fire-and-forget work, use context.WithoutCancel plus your own timeout, and track the goroutines so graceful shutdown can wait for them.
• Panics in those child goroutines crash the server. Only the handler goroutine itself is protected.
• Slowloris-style attacks keep many goroutines alive when timeouts are missing.

srv := &http.Server{
	Addr:              ":8080",
	ReadHeaderTimeout: 5 * time.Second,
	IdleTimeout:       60 * time.Second,
	Handler:           h,
}

What the interviewer wants to hear: goroutine-per-connection is a good default, as long as you add timeouts, limits and lifecycle management.