Golang Go语言中 net/http Client 的某些参数不是并发安全的？
Golang Go语言中 net/http Client 的某些参数不是并发安全的？
在官方文档中有提到 net/http client 是协程安全的，应该复用。
The Client's Transport typically has internal state (cached TCP connections), so Clients should be reused instead of created as needed. Clients are safe for concurrent use by multiple goroutines.
但使用 Client 发起请求时，有一部分请求的设置是以函数或字段的方式放在 Client 的参数中的。例如 Proxy 代理、重定向检查、超时设置。要设置的话必须像以下这般设置：
func RedirectFunc(req *http.Request, via []*http.Request) error {
if len(via) > 5 {
err := &RedirectError{r}
return WrapErr(err, "RedirectError")
}
return nil
}
client.CheckRedirect = RedirectFunc // 设置重定向
这样的话就会造成一个问题，在并发的过程中如果要更改重定向次数的话，就会有并发安全问题，设置 Proxy 代理和超时时间也有这个问题。
比如在这样一个假设情况中，我现在有 10000 个请求需要并发，每个请求需要设置不同的特定 Proxy 代理。那么这时候使用全局的 Client，在每个协程中更改 client.CheckRedirect 函数，然后发起请求，显然会有并发问题，发起请求时使用的并不一定是指定的那个 Proxy。
想了想解决的办法：
- 每个请求新建一个 Client ？
- 把更改参数和请求一起加锁锁起来？
请问这种情况有靠谱的解决方法吗？
更多关于Golang Go语言中 net/http Client 的某些参数不是并发安全的？的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
大兄弟，人家说的是让你复用 Transport，划重点 。
更多关于Golang Go语言中 net/http Client 的某些参数不是并发安全的？的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
抱歉，没仔细看题。我仔细看了文档，感觉这里的复用应该不是只并发的复用，Client 应该是有状态的。GitHub 上 golang 的官方 issue 里也有人提到关于复用的另一个问题：
https://github.com/golang/go/issues/26095
你对并发安全理解有问题吧，这个明显你修改的话是在请求过程中还是使用你指定的 Func，但是你每个都修改，client 只会使用你最后指定的参数，这样看上去是不是没问题了？
如果是单纯 proxy，你有个简单方案是按照 proxy 生成对应的 client，然后使用就行了
嗯嗯，我也知道官方文档的复用大部分意思指的是复用连接。
但代理、超时、重定向这些设置，只有 Client 和 Transport 这种级别可以设置，在 Request 这个级别无法指定到特定的请求上。现在又需要复用 Client，但在并发的时候更改 Client 里的这些设置又不是并发安全的，就很头疼。
目前就是需要把 超时、代理、重定向 这些设置到单个 Request 上，但 net/http 不提供，就只能设置在 Client 上。
并发的时候改 Client 就会有问题，因为 Client 需要复用，是全局的。
go 文档里说的复用应该是指复用 tcp 连接（ keep-alive ），你这种换代理的方式很显然要重新连接。你想要的只是复用 Client 这一个结构体，还是老老实实不同的 proxy 创建不同的 Client 对象吧，应该不会多出多少开销。
CheckRedirect 这个属性为什么需要修改呢？
这个函数的签名提供的两个 req *http.Request, via []*http.Request 参数还不够做业务判断吗？
我的意思是，client 创建完成了，在生命周期内保持 CheckRedirect 不变化， 所有需要处理重定向而需要作区分对待的统一在 CheckRedirect 函数里实现不行吗？
不是，是 Request 里根本没有设置重定向，超时，代理这些的地方，只能去 client 里设置。并发的时候要改这些设置就只能改 client，并发的时候改 client 就有问题。
是 Request 里根本没有设置重定向，超时，代理这些的地方，只能去 client 里设置。并发的时候要改这些设置就只能改 client。不然就只有建新的 Client。
可以试试使用 NewRequestWithContext 在 Request 里面附加上下文信息，在 CheckRedirect 或者 Proxy 函数里面从 Request.Context 拿到 Context 来切换对应的策略。
这个问题我之前在基于 net/http 开发一个网络请求库的时候也思考过，能不能做到想 python requests 库那样为每一个 HTTP 请求单独设置证书校验逻辑、代理等控制策略，而且做到并发安全。
可 go 的方案就是 client 只初始化 1 次就好，之后不应该再修改，要实现我想要的功能就必须动态修改 client，文档告诉我们 client 是并发安全的，即使你在多个 goroutines 修改 client 也不会出现数据竞争，但 client 在发起请求时只会使用最近修改的值，并不能达到我所期望的效果（每个请求对应不同的策略）。
我想到可行的方法就是为每一个请求克隆一个 client，但这样势必会影响性能。最后一刀切，凡是修改 http client 的我都没提供 api 去简化，有这种需求的话创建不同的 client 就是。
18 楼提到 context 我觉得也是不可行的，因为本质上你还是要动态修改 client，反而额外增加了类型断言的开销。
#22 因为 net/http 设置代理 /重定向策略都是在 client 设置的，即便你在 Request 对象上下文携带了相关参数，你要发起请求就要经过 client。
#26 感谢，这个对 Proxy，CheckRedirect 可行，因为它们跟 request 关联，对于 transport 其它跟 request 没有关联的参数就无解了，比如像 python requests 的 verify
在Golang的net/http包中，Client类型确实有一些参数和内部状态不是并发安全的。这主要涉及到Client的Transport字段、Timeout、CheckRedirect等属性以及某些内部缓存机制。
-
Transport：
Client的Transport字段负责实际的网络连接和请求发送。默认情况下，Transport会维护一个连接池，这个连接池不是线程安全的。如果在多个goroutine中共享一个Client实例，并试图同时修改其Transport字段（例如更换底层的http.RoundTripper），可能会导致不可预期的行为。 -
Timeout：
Client的Timeout属性用于设置整个请求（包括连接、读取响应等）的超时时间。修改这个值需要在无并发访问的情况下进行，否则可能会导致竞态条件。 -
CheckRedirect：这个回调函数用于处理重定向。如果在并发环境下修改它，也可能导致竞态条件。
为了确保并发安全，通常的做法是每个goroutine使用自己的Client实例，或者通过适当的同步机制（如互斥锁）来保护对共享Client实例的访问。然而，更推荐的做法是尽量重用Client实例（特别是Transport），因为连接复用可以显著提高性能，只是需要确保这些实例不在并发情况下被修改。
总之，在使用net/http.Client时，要特别注意并发访问的问题，以避免潜在的问题。
