I put some code snippets on here.

Please summarize the relevant properties of those snippets — they don't compile, and it's not obvious what the elided code does or how that interacts with the call to Close.

Note per https://golang.org/pkg/net/http/#Server.Close:

Close does not attempt to close (and does not even know about) any hijacked connections, such as WebSockets.

Also note that closing a connection does not terminate any associated goroutine running ServeHTTP: those goroutines will continue to run until they decide to return (perhaps as a result of noticing a failed write to the response). In particular, it is possible for the ServeHTTP goroutine to start, then the Close call to execute, and finally the ServerHTTP goroutine to become scheduled and run.

So the details of what those nested servers are actually doing are very important, as are the details about when exactly you expect ServeHTTP to no longer be called.

Thanks for your reply.

Please summarize the relevant properties of those snippets — they don't compile, and it's not obvious what the elided code does or how that interacts with the call to Close.

First we create an object of type WebSvrImpl, then call ListenAndServe, now we can recv the http request from client.

Those requests are used for loading some business data from DB.

After serving all the http requests we call Close on such object and stop the whole application.

Then we expect the server will not recv the request from any client.

As you say

Also note that closing a connection does not terminate any associated goroutine running ServeHTTP

we expect that the http.Server should return some error code to indicate it had been stoped during the time we call Close and the end moment of server.

But we still got http request which was handled by ServeHTTP.

Thanks.

we expect that the http.Server should return some error code to indicate it had been stoped during the time we call Close and the end moment of server.

Close literally closes the connection. There is no opportunity to return any error code at that point.

If you want the server to shut down gracefully, you can use the Shutdown method. With that approach, you'd need to communicate the start of shutdown to the handlers by whatever mechanism you like (such as canceling a context.Context), and they can report an appropriate error explicitly.

@pingworld did this adequately answer your question?

Thanks, we have no other questions! We have solved this problem!

All requests have been processed after waiting for several seconds when close the whole app.