在技术层面上的规则，很多帖子已经说明白了。
今天在开发一个小管理系统里用户和文件管理模块时，需要了包文件名上的控制。
了解一点Golang包划分规则的，就该知道，import中是完整路径，调用方法时是“方法所在包名”.“方法名”，如果有两个方法，它们的完整路径是不一样的，但是包名相同，那么你调用的时候就得给另外一个取一个别名。
别名我是很反对的，原因是因为原来做过的Java开发中，有目录结构按模块/分层（即MVC）/文件名来发划分的，那么用户、文件、角色等目录下，都会存在controller、dao、service等文件夹，如果有哪个go文件，作为复杂逻辑的业务方法，调用了好多，那么别名得起多少个才能不混淆。
导入包本来靠IDE好不容易变简单，如果照搬Java的话肯定又重新变复杂了。
在我下载到的一些小项目中，我看到作者把属于一类的go文件都放到一个文件夹下。比如user_controller.go，file_controller.go，放到controller下，即使它们不是一个模块中的。以前在Java中我有过这样的经验，是因为一个老项目Hibernate指定路径扫描hbm.xml文件，那么把Bean都放到一个目录下，受这个影响这个老项目里还有很多类似的做法。
不过我个人不大愿意接受这种方法，当时为了改一个xml而在一个文件夹中下拉出那么多文件来的感觉实在很奇怪。用工具在文件夹中找一次这个文件不是什么太费劲的事，但是如果模块划分合理，我们就可以省下这份精力。
Golang的最佳实践我是没什么经验的，不过我个人之所以用Golang Iris框架，本就是因为其快速，API使调用解耦的原因。那么既然要解耦，我想到了一个非技术上的小办法。
我把router（或API）全部放到一个文件夹下，不同的模块使用不同的router，遇到交叉的模块，也可以专门设置一个go文件，比如叫user_role.go。不过更推荐的办法是，交叉的模块应该通过调用彼此暴露的API，第一是这样就可以向其他模块的API隐藏自己的业务层，真正做到API访问，其次是这些API都在router下，也就不需要导入各种包了。
其他的持久层、逻辑层（router用到的handler）都还是按模块和类别划分好，规模庞大的可以多分几级。在暴露到API时，只有自己的router才会调用自己模块所在包下的方法，那么也不会频繁发生别名冲突的问题了。
如果你有更好的办法，那么我是很期待你分享出来的。