高端网站建设百度,网站悬浮qq,seo分析案例,最新营销模式有哪些Go语言是使用包#xff08;package#xff09;作为基本单元来组织源码的#xff0c;可以说一个Go程序就是由一些包链接在一起构建而成的。虽然与Java、Python等语言相比这算不上什么创新#xff0c;但与祖辈C语言的头文件包含机制相比则是“先进”了许多。 编译速度快是这种… Go语言是使用包package作为基本单元来组织源码的可以说一个Go程序就是由一些包链接在一起构建而成的。虽然与Java、Python等语言相比这算不上什么创新但与祖辈C语言的头文件包含机制相比则是“先进”了许多。 编译速度快是这种“先进性”的一个突出表现即便每次编译都是从零开始。Go语言的这种以包为基本构建单元的构建模型使依赖分析变得十分简单避免了C语言那种通过头文件分析依赖的巨大开销。
Go编译速度快的原因具体体现在以下三方面。
● Go要求每个源文件在开头处显式地列出所有依赖的包导入这样Go编译器不必读取和处理整个文件就可以确定其依赖的包列表。
● Go要求包之间不能存在循环依赖这样一个包的依赖关系便形成了一张有向无环图。由于无环包可以被单独编译也可以并行编译。
● 已编译的Go包对应的目标文件file_name.o或package_name.a中不仅记录了该包本身的导出符号信息还记录了其所依赖包的导出符号信息。
这样Go编译器在编译某包P时针对P依赖的每个包导入比如导入包Q只需读取一个目标文件即可比如Q包编译成的目标文件中已经包含Q包的依赖包的导出信息而无须再读取其他文件中的信息。 Go语言中包的定义和使用十分简单。通过package关键字声明Go源文件所属的包
// xx.go
package a
...
上述源码表示文件xx.go是包a的一部分。
使用import关键字导入依赖的标准库包或第三方包
package mainimport (fmt // 标准库包导入a/b/c // 第三方包导入
)
func main() {
c.Func1()
fmt.Println(Hello, Go!)
}很多Gopher看到上面的代码会想当然地将import后面的“c”“fmt”与c.Func1()和fmt.Println()中的c和fmt认作同一个语法元素包名。但在深入学习Go语言后大家会发现事实并非如此。
比如在使用实时分布式消息框架nsq提供的官方client包时我们的包导入是写成这样的
import github.com/nsqio/go-nsq但在使用该包提供的导出函数时我们使用的不是go-nsq.xx而是
nsq.xxx
q, _ : nsq.NewConsumer(write_test, ch, config)很多Gopher在学习Go包导入时或多或少有些疑惑import后面路径中的最后一个分段到底代表的是什么是包名还是一个路径
在本条中我就和大家一起来深入探究和理解一下Go语言的包导入。
Go程序构建过程
我们先来简单了解一下Go程序的构建过程作为后续理解Go包导入的前导知识。和主流静态编译型语言一样Go程序的构建简单来讲也是由**编译compile和链接link**两个阶段组成的。
一个非main包在编译后会对应生成一个.a文件该文件可以理解为Go包的目标文件 该目标文件实际上是通过pack工具 G O R O O T / p k g / t o o l / d a r w i n a m d 64 / p a c k 对 . o 文件打包后形成的。默认情况下在编译过程中 . a 文件生成在临时目录下除非使用 g o i n s t a l l 安装到 GOROOT/pkg/tool/darwin_amd64/pack对.o文件打 包后形成的。默认情况下在编译过程中.a文件生成在临时目录下除非使用go install 安装到 GOROOT/pkg/tool/darwinamd64/pack对.o文件打包后形成的。默认情况下在编译过程中.a文件生成在临时目录下除非使用goinstall安装到GOPATH/pkg下Go 1.11版本之前否则你看不到.a文件。如果是构建可执行程序那么.a文件会在构建可执行程序的链接阶段起使用。
标准库包的源码文件在 G O R O O T / s r c 下面而对应的 . a 文件存放在 GOROOT/src下面而对应的.a文件存放在 GOROOT/src下面而对应的.a文件存放在GOROOT/pkg/ darwin_amd64下以macOS为例如果是Linux系统则是linux_amd64
// Go 1.16
$tree -FL 1 $GOROOT/pkg/darwin_amd64
├── archive/
├── bufio.a
├── bytes.a
├── compress/
├── container/
├── context.a
├── crypto/
├── crypto.a
...“求甚解”的读者可能会提出这样一个问题构建Go程序时编译器会重新编译依赖包的源文件还是直接链接包的.a文件呢下面通过一个实验来给大家答案。
Go 1.10版本引 入了build cache为了避免build cache给实验过程和分析带来的复杂性我们使用Go1.9.7版本来进行这个实验。 我们建立实验环境的目录结构如下
chapter3-demo1
├── cmd/
│ └── app1/
│ └── main.go
└── pkg/
└── pkg1/
└── pkg1.go
由于仅是为了演示pkg1.go和main.go的源码都很简单
// cmd/app1/main.go
package main
import (
github.com/bigwhite/effective-go-book/chapter3-demo1/pkg/pkg1
)
func main() {
pkg1.Func1()
}
// pkg/pkg1/pkg1.go
package pkg1
import fmt
func Func1() {
fmt.Println(pkg1.Func1 invoked)
}进入chapter3-demo1执行下面的命令
$go install github.com/bigwhite/effective-go-book/chapter3-demo1/pkg/pkg1之后我们就可以在
$GOPATH/pkg/darwin_amd64/github.com/bigwhite/effective-
go-book/chapter3-demo1/pkg下看到pkg1包对应的目标文件pkg1.a
$ls $GOPATH/pkg/darwin_amd64/github.com/bigwhite/effective-go-book/chapter3-demo1/pkg
pkg1.a我们继续在chapter3-demo1路径下编译可执行程序app1
$go build github.com/bigwhite/effective-go-book/chapter3-demo1/cmd/app1执行完上述命令后我们会在chapter3-demo1下看到一个可执行文件app1执行该文件
$ls
app1* cmd/ pkg/
$./app1
pkg1.Func1 invoked这符合我们的预期但现在我们仍无法知道编译app1使用的到底是pkg1包的源码还是目标文件pkg1.a因为目前它们的输出都是一致的。
修改一下pkg1.go的代码
// pkg/pkg1/pkg1.go
package pkg1
import fmt
func Func1() {
fmt.Println(pkg1.Func1 invoked - Again)
}重新编译执行app1得到如下结果
$go build github.com/bigwhite/effective-go-book/chapter3-demo1/cmd/app1
$./app1
pkg1.Func1 invoked - Again究竟是路径名还是包名
通过前面的实验我们了解到编译器在编译过程中必然要使用的是编译单元一个包所依赖的包的源码。
而编译器要找到依赖包的源码文件就需要知道依赖包的源码路 径。这个路径由两部分组成基础搜索路径和包导入路径。
基础搜索路径是一个全局的设置下面是其规则描述。 1所有包无论是标准库包还是第三方包的源码基础搜索路径都包括 G O R O O T / s r c 。 2 在上述基础搜索路径的基础上不同版本的 G o 包含的其他基础搜索路径有不同。● G o 1.11 版本之前包的源码基础搜索路径还包括 GOROOT/ src。 2在上述基础搜索路径的基础上不同版本的Go包含的其他基础搜索路径有不同。 ● Go 1.11版本之前包的源码基础搜索路径还包括 GOROOT/src。2在上述基础搜索路径的基础上不同版本的Go包含的其他基础搜索路径有不同。●Go1.11版本之前包的源码基础搜索路径还包括GOPATH/src。 ● Go 1.11Go 1.12版本包的源码基础搜索路径有三种模式 ● 经典gopath模式下GO111MODULEoff G O P A T H / s r c 。● m o d u l e − a w a r e 模式下 G O 111 M O D U L E o n GOPATH/src。 ● module-aware模式下GO111MODULEon GOPATH/src。●module−aware模式下GO111MODULEonGOPATH/pkg/mod。 ● auto模式下GO111MODULEauto在 G O P A T H / s r c 路径下与 g o p a t h 模式相同在 GOPATH/src路径下与gopath模式 相同在 GOPATH/src路径下与gopath模式相同在GOPATH/src路径外且包含go.mod与module-aware模式相同。 ● Go 1.13版本包的源码基础搜索路径有两种模式 ● 经典gopath模式下GO111MODULEoff G O P A T H / s r c 。● m o d u l e − a w a r e 模式下 G O 111 M O D U L E o n / a u t o GOPATH/src。 ● module-aware模式下GO111MODULEon/auto GOPATH/src。●module−aware模式下GO111MODULEon/autoGOPATH/pkg/mod。 ● 未来的Go版本将只有module-aware模式即只在module缓存的目录下搜索包的源码。 而搜索路径的第二部分就是位于每个包源码文件头部的包导入路径。基础搜索路径与 包导入路径结合在一起Go编译器便可确定一个包的所有依赖包的源码路径的集合这个 集合构成了Go编译器的源码搜索路径空间。看下面这个例子
// p1.go
package p1
import (
fmt
time
github.com/bigwhite/effective-go-book
golang.org/x/text
a/b/c
./e/f/g
)
...包名冲突问题
同一个包名在不同的项目、不同的仓库下可能都会存在。同一个源码文件在其包导入 路径构成源码搜索路径空间下很可能存在同名包。比如我们有另一个chapter3-demo2 其下也有名为pkg1的包导入路径为github.com/bigwhite/effective-go-book/chapter3- demo2/pkg/pkg1。如果cmd/app3同时导入了chapter3-demo1和chapter3-demo2的pkg1包 会发生什么呢
// cmd/app3
package main
import (
github.com/bigwhite/effective-go-book/chapter3-demo1/pkg/pkg1
github.com/bigwhite/effective-go-book/chapter3-demo2/pkg/pkg1
)
func main() {
pkg1.Func1()
}编译一下cmd/app3
$go build github.com/bigwhite/effective-go-book/chapter3-demo1/cmd/app3
# github.com/bigwhite/effective-go-book/chapter3-demo1/cmd/app3
./main.go:5:2: pkg1 redeclared as imported package name
previous declaration at ./main.go:4:2我们看到的确出现了包名冲突的问题。怎么解决这个问题呢还是用为包导入路径下 的包显式指定包名的方法
package main
import (
pkg1 github.com/bigwhite/effective-go-book/chapter3-demo1/pkg/pkg1
mypkg1 github.com/bigwhite/effective-go-book/chapter3-demo2/pkg/pkg1
)
func main() {
pkg1.Func1()
mypkg1.Func1()
}上面的pkg1指代的就是chapter3-demo1/pkg/pkg1下面的包mypkg1则指代的是chapter3-demo1/pkg/pkg1下面的包。就此包名冲突问题就轻松解决掉了。
我们通过实验进一步理解了Go语言的包导入Gopher应牢记以下几个结论
● Go编译器在编译过程中必然要使用的是编译单元一个包所依赖的包的源码
● Go源码文件头部的包导入语句中import后面的部分是一个路径路径的最后一个分段是目录名而不是包名
● Go编译器的包源码搜索路径由基本搜索路径和包导入路径组成两者结合在一起后编译器便可确定一个包的所有依赖包的源码路径的集合这个集合构成了Go编译器的源码搜索路径空间
● 同一源码文件的依赖包在同一源码搜索路径空间下的包名冲突问题可以由显式指定包名的方式解决。
