写代码，常常是摸着石头过河。写 Go 的时候，也许你碰到过一个问题， main 包里的函数，没法从外面 import。这是一个设计，牵扯到不少细节。我们今天来看一下为什么 Go 如此设计，且影响如何。
Go 的设计哲学里，简洁二字特别重要。有多重要？你去看 Go 的源码，发现规则明确，一切都讲模块化，讲独立性。具体到 main 包，程序的入口总是在这儿。这就像开一家店，main 包就是你门店的大门，顾客进来第一脚踏进门槛，就需要知道这是哪儿、有什么货。至于后厨怎么运营，人家不需要过问。函数放在这儿，天然是启动程序时使用，服务于整个程序生命周期的开始。一旦放进 main，就有了点“私有”的意味。
再说 Go 的模块化思想。他们希望各部分功能切割明确。就像切菜，肉是肉，菜是菜。那你总不能一边切肉，一边切菜，刀下乱了，脑袋也晕了。main 包里放了程序启动的逻辑，明确给了任务。那其他的模块，其他包里的代码，就跟这些入口逻辑隔离了。这样做有个明显的好处，责任明确，功能分割开，容易测试，也容易维护。出了问题，顺藤摸瓜，一会儿就能找到源头。把 main 里的函数到处导入使用，其实就是打乱了界限。何必呢？搞乱了，最后头痛的还是自己。
想象一下场景，main 里的东西随便给外边用。这时候，程序一点一点扩展，包之间的依赖逐步混乱，一个小小的改动都会冒出莫名其妙的问题。项目越来越大，总有一天你会想，当初要是恪守设计原则，今天不至于摸着脑袋心里骂娘。Go 这是让你别自找麻烦，简单事儿简单做，该是什么就是什么。
Go 的语法还强调了一件事，不鼓捣那些有的没的。没有类、继承这套面向对象的玩法，它取而代之的是组合与接口的运用。那在包之间的交互层面，亦是如此。你提供某个功能，导出一个接口，明确告诉外界我能做什么，具体实现，无关的人没必要知道。main 包就这么一层窗户纸，里面的东西自己用就够了，何必要让别人探头探脑？既没必要，也不合适。
另外一个层面就是工具链的支持。你去编译 Go 代码时，命令行下太熟悉不过。go build 就那么一个命令下去，明确地把整个项目打包、构建。而这个打包过程中，程序启动的逻辑必须紧密贴合编译过程，端口需要启动吧，配置需要初始化吧，这些事儿依赖 main 包来做。那 main 里的内容能随便分给别人吗？这不是乱套了吗？编译器的逻辑、依赖的清算，都需要依赖 main 形成固定的起点，这也是严谨的设计追求的一部分。某种程度上说，保持 main 包不被外部侵入，避免了整个项目的风险积聚。最终造出来的东西，才是条理清晰的，不出问题的构建品。
对咱写程序的，早些年可能向往过那些花里胡哨的架构，追捧复杂的系统设计，可后来认真反思，程序真的需要高不可攀吗？最终服务好了人，才是好的代码。Go 这个特性设计的确让人反思，设计的取舍哪里来、哪里去。图个简单，节省心力，也不容易出错。现实写代码的情况如此，经常不多写一个字，int、string、function，功能有限而确定，少一份灵活也少一份潜在的风险。不见得必要去拼智商去复杂解决一件很简单的事儿。试图到处共享一切方法，反而最后的牵连广了，失误概率跟着攀升，而这些原本可以无须发生的。Go 教会我在代码世界里踏实一些。最终你不是最炫的那个，你是稳的那个就挺好。
最终 Go 的设计在这里体现了对现实开发问题的透彻理解，懒且聪明。明确分层，每个模块形成约束，这份规矩，最终可以带来和平、带来宁静。
