socketTimeoutMS控制已连接后读响应的超时，合理值为5000–15000毫秒；它区别于connectTimeoutMS，后者管建连阶段；超时需结合DNS、TLS、锁竞争、服务端负载等分层排查。
socketTimeoutMS 控制的是“已连上但读不到响应”的等待上限，设太大（比如 60 秒）会让慢查询拖垮整个连接池，设太小（如 100 毫秒）又会误杀正常长查询——合理值通常在 5000–15000 毫秒之间，具体得看你的查询平均耗时和业务容忍度。
socketTimeoutMS 和 connectTimeoutMS 容易混淆
前者是 TCP 连接建立后，等服务端返回数据的超时；后者是连 TCP 都没连上的超时。你看到 socket.timeout: The read operation timed out，说明连接已通，问题出在 DNS、TLS 握手、认证、锁竞争或服务端负载上，不是网络不通。
-
ConnectionTimeoutError：查telnet your-host 27017或nc -zv your-host 27017 -
socket.timeout：优先检查 MongoDB 日志里有没有慢查询、db.currentOp()是否有阻塞操作、云环境是否放行了 SRV 查询（UDP 53 端口） - URI 中写
socketTimeoutMS=10000仅在srv=False时生效；若 DNS 有 SRV 记录，PyMongo 4.0+ 会自动忽略它
爬虫/高频写入场景下 socketTimeoutMS 必须调低
每秒几百次写入时，一个慢查询卡住 30 秒（默认值），会迅速占满连接池，后续请求全堵在 serverSelectionTimeoutMS 阶段，表现为 ServerSelectionTimeoutError。
- 建议设为
socketTimeoutMS=5000，配合maxPoolSize=50和minPoolSize=5 - 避免在循环里新建
MongoClient，全局复用单例实例 - 写操作加
write_concern={"w": 1, "j": False}减少服务端确认开销，降低超时概率
事务 commit 阶段 socketTimeoutMS 影响最大
事务空闲超时由服务端 transactionLifetimeLimitSeconds（默认 60 秒）控制，但 commit_transaction() 的网络等待仍受 socketTimeoutMS 约束。如果这个值设成 30000，而服务端因空闲已终止事务，客户端发 commit 请求时可能收不到任何响应，直接触发 socket.timeout。
- 事务内操作应尽量轻量，避免嵌套 HTTP 调用或文件 I/O
-
commit_transaction()可额外加max_commit_time_ms=5000，这是服务端级超时，比socketTimeoutMS更精准 - 不要把
socketTimeoutMS设得比max_commit_time_ms还小，否则网络层先超时，服务端逻辑超时根本没机会触发
真正难调的不是数值本身，而是分清超时发生在哪一层：TCP 连接？DNS 解析？TLS 握手？服务端执行？还是客户端线程调度？打印 client.options.pool_options.socket_timeout_ms 确认设置是否真被加载，比反复猜更可靠。
