关于Go包的以下断言是否准确？
import "package_name"从名为package_name的目录中导入所有文件，假设在$ GOPATH中找到，该变量包含用户go目录，或者在标准go安装目录树中。
文件通常会声明package package_name。但他们并不需要。实际上，如果在导入的package_name目录中找到该文件，import "package_name"也会导入包含行package foo的文件。
所有大写的函数都将通过package package_name声明中给出的名称访问 - 例如：
package_name.Function_in_file_that_declares_package_name或other_than_package_name.Function_in_file_that_declares_other_than_package_name
go install - 来自包目录。但是，go将拒绝安装与其内置包目录相同的目录。例如，你不能安装一个字符串目录，因为go已经有了一个内置包“strings”的字符串目录。但是，用户可以通过创建my_strings目录并放置一个在其中声明package strings的文件，将函数附加到strings包而不改变内置字符串文件夹。现在，import my_strings将加载使用strings.Function_name访问的额外用户定义字符串函数。 总之，import关键字用于从给定目录加载文件。关键字package创建一个名称空间，以便从该文件外部访问大写函数。
我能正确理解以上所有内容吗？
答案 0 :(得分：4)
“import”的参数是import_path，而不是包名。它使$GOPATH/src/import_path中找到的包中的导出实体在“import”子句出现的文件范围内可用。
单个目录中的所有* .go文件（*_test.go文件除外，文件// +build ignore除外）必须在package name子句或go构建系统中使用相同的名称将拒绝它。
不大写，但属于Unicode类别Lu。不是功能，而是任何TLD实体。
不，您可以使用其导入路径从任何目录安装任何软件包。是的，stdlib中的包具有优先级，不能“覆盖”。但是，您可以使用eg有效地“替换”stdlib包。 import strings "github.com/foo/mystrings"。但是，效果仅为本地/文件。
总之，不，导入用于使文件范围内的其他包中的实体可用。关键字“package”不会创建命名空间。 “import”的效果是文件范围的，请参见前面的句子，通常导入的实体由限定名称引用。该限定符是一种命名空间，但请注意，“导出器”（package foo）不会控制它。相反，控件位于“导入器”端：import whatever_local_name "whatever_import_path"。但是，默认限定符是导入路径的基本名称。
“我们都同意吗？”
完全没有。
答案 1 :(得分：4)
即使听起来很苛刻：几乎所有假设都是完全错误的。
请查看http://golang.org/doc/effective_go.html#package-names和http://golang.org/ref/spec#Packages，并且不要将import视为与C include相当的Go。
Go的包更像是预编译库，而import "some/path/foo"更像是在foo.a中链接（但也使得导出的实体在 - {1}}下可用。
现在看看http://golang.org/doc/code.html，应该清楚哪些包以及它们的使用方式。