Go语言连接数据库为何采用同步写法？是否会阻塞线程？

先直接给结论：这段代码里的mongo.Connect从Go代码执行流的视角看，当前goroutine会停在这里等待操作返回——要么成功返回client实例，要么返回err，但是这个等待过程不会阻塞对应的操作系统线程，你看到的同步写法只是上层暴露的语法体感，底层IO走的是非阻塞实现。

核心实现原理 #

你有Node.js开发经验，可以对照你熟悉的事件循环模型理解，两者底层IO复用的思路同源，但Go把异步调度的逻辑完全收进了runtime层，对上层开发者屏蔽了异步写法的复杂度：

• Node.js的异步IO靠libuv做封装，遇到IO等待时会把操作交给系统异步接口/后台线程池处理，完成后把回调塞回事件循环队列执行，你必须写回调、Promise、async/await这类异步语法，才能避免卡住事件循环的主线程。
• Go用的是goroutine + netpoll网络轮询器的调度模型，上层完全不用感知异步逻辑：
  • 标准库、绝大多数主流开源SDK的网络IO操作（数据库连接、HTTP请求、RPC调用等），底层都对接了操作系统提供的IO多路复用能力（Linux下epoll、macOS下kqueue、Windows下IOCP）。
  • 当你调用mongo.Connect触发网络IO，一旦进入等待远端响应的阶段，Go runtime会立刻把当前运行的goroutine挂起，把这个IO的就绪事件注册到netpoll的监听列表中，之前和这个goroutine绑定的OS线程会被直接释放，转而去执行其他已经处于就绪状态的goroutine，根本不会空等IO返回浪费CPU资源。
  • 等数据库返回连接响应、对应socket数据就绪时，netpoll会第一时间收到系统通知，runtime会把之前挂起等待这个IO的goroutine重新标记为可运行，调度到空闲的OS线程上继续执行后续逻辑，从代码视角看就是函数同步返回了结果和错误。

整个调度过程对写业务代码的人完全透明，你不需要手动写回调、不需要给函数加特殊的异步标记，从上到下按顺序写同步逻辑就行，错误也直接按同步返回的err值判断，这就是Go里IO操作普遍采用同步写法的核心原因。

补充个Mongo Go Driver的使用细节：当前版本的mongo.Connect不会等TCP连接完全握手完成才返回，只是初始化client实例、启动后台建连流程，如果要确认连接真的可用，需要后续额外调用client.Ping方法做检查，这个是API本身的设计，和Go的IO调度模型无关。

内容的提问来源于stack exchange，提问作者JuntaA