net/http: Why not close the conn directly instead of put the conn into a new list?

I read golang's source code recently, and find a place that doesn't make sence.

if t.MaxIdleConns != 0 && t.idleLRU.len() > t.MaxIdleConns { 
 	oldest := t.idleLRU.removeOldest() 
 	oldest.close(errTooManyIdle) 
 	t.removeIdleConnLocked(oldest) 
 } 

the code is here : https://github.com/golang/go/blob/96c8cc7fea94dca8c9e23d9653157e960f2ff472/src/net/http/transport.go#L984-L988

question:
when idleConn's length > t.MaxIdleConns, why not close the conn directly instead of put the conn into a new list. at the same time, remove the oldest conn in the list. As I understand it, it's simple to close the redundant connection, and it turns out to be corrent.

I'd speculate that the reason is that the server (the remote) is not by any means oblidged to keep an idle connection open, and even if it decides to do so, it's not oblidged to keep it open for as long as the client requested.
Another possible problem is that idling TCP sessions can be proactively terminated by indermediate network nodes (for instance, NAT devices usually have to maintain certain state for each TCP session they route and so they are "interested" in getting rid of the sessions they deem to be dead); TCP keepalives may help but they should be enabled—which is not always the case,—and their "pings" should be frequent enough for an intermediate node to consider such session alive, which, again, is also not always the case.

These issues may easily lead for a session idling for some time to be closed either by the server or by an intermediate network node.
Add to that the fact that basically net/http has no simple means to know that a particular idle connection has really been closed and became unusable in the time frame since the last HTTP session has been performed on it and until net/http pulled that connection for carrying out another session.

If you'll read the code a bit further, you'll find out that net/http tries to use an idle connection and if it finds it's dead, it'll pick the next one, and will repeat that until one works or it will be forced to establish a new connection.

Hence a more recent connection simply has greater chance of being ready to serve another HTTP session.

Add to that another line of reasoning, somewhat related to the presented above: the server might have a limit on the number of simultaneously active connections—total, or per (source) host, or both,—and in production setups it usually has. By this logic, if a connection to it succeeds, it may mean that some old connection beleived by the client to be alive albeit idle, had already be closed by the server—so it were able to create a new connection while staying within its configured limits of the number of active connections. Of source, such logic is just a speculation, but not exactly unfounded.