如果你说的是Go语言编译器提供的可执行文件，那么答案就是“是或否--这取决于”：
在大多数情况下，生成的可执行程序 * 不 * 依赖于C运行库。
然而，在某些平台上，在某些情况下，C运行库会被动态地链接进来。特别是在Linux上使用DNS解析时，Go语言版本〈1.5的情况就是这样：运行时依赖于平台的libc实现来处理这样的解析。在1.5中，这已经被修改。
另一种可能的情况是（IIRC）Solaris，它没有提供直接访问内核的系统调用和requires routing these calls through the platform's libc的稳定方法。
还有一种情况：使用cgo，它是Go语言代码与外来C语言代码的接口层，使用cgo会使Go语言程序依赖于C运行库，注意，你可能不会直接使用cgo，但是你可能使用的一个或多个第三方包可以使用cgo，并且程序最终会依赖于C运行库。

我认为公认的答案是正确的，但导入'net'包的二进制文件通常依赖于c运行时，即使在go 1.10和Unix中也是如此。
下面是简单echo服务器的示例：

package main

import (
        "io"
        "log"
        "net"
)

func main() {
        ln, err := net.Listen("tcp", ":8080")
        if err != nil {
                log.Fatal(err)
        }

        for {
                conn, err := ln.Accept()
                if err != nil {
                        log.Print(err)
                        continue
                }

                _, err = io.Copy(conn, conn) // blocked until the client closes the conn.
                if err != nil {
                        log.Print(err)
                        continue
                }

                if err = conn.Close(); err != nil {
                        log.Print(err)
                }
        }
}

生成它并检查其依赖项：

$ go build ./libc_check.go
$ ldd ./libc_check
        linux-vdso.so.1 =>  (0x00007ffe34fc1000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc005d4e000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc005984000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc005f6b000)

这是因为正如发行说明所指出的，“如何运行解决程序的决定适用于运行时，而不是构建时”。
要避免这种依赖性，请使用如下的“netgo”build标记：

$ go build -tags netgo ./libc_check.go
$ ldd ./libc_check
        not a dynamic executable

如果你指的是LibC，Go语言并不依赖于它，Go语言有自己的标准库，包括文件I/O、网络和内存管理等常用函数的实现，因此它不依赖于libc或其他任何外部库。