golang是类型严格的语言（好像是这样说吧），同时也没有范型，还没有继承（这点实在不知道是怎么考虑的），基于这两点，golang的ORM不可能像php那样设计，更不可能做到Eloquent那样方便易用。
一、基于golang的ORM可以和Laravel Eloquent相媲美的
golang是类型严格的语言（好像是这样说吧），同时也没有范型，还没有继承（这点实在不知道是怎么考虑的），基于这两点，golang的ORM不可能像php那样设计，更不可能做到Eloquent那样方便易用。
当然，golang有struct的组合可以当集成，但是，假设给DB结构体安装上一堆方法，
type DB struct {
}
func (d *DB) Where(option interface{}) {
Type := reflect.TypeOf(d).Elem()
for i := 0; i < Type.NumField(); i++ {
field := Type.Field(i)
// do something
}
}
如果在User结构体组合DB结构体
type User struct {
*gorm.DB
}
调用user内的where方法实际上是调用了DB内的where方法，反射不出字段，所以，在golang的orm设计中，通常是这样做的：
type DB struct {}
func （db *DB） where（）{}
func （db *DB） select（）{}
使用的时候：
type User struct {} // 定义一个user模型
var db DB //初始化db结构体
var user User // 初始化User结构体
db.where().select(&user)
上面是两个语言在语言层面就造成的差异，看个人习惯，用起来都不难，golang的GORM和XORM都很好用，我做项目的时候用的是GORM。
至于类似Eloquent功能的基于golang的ORM，我找了很久，没有找到，毕竟Eloquent内有非常多的laravel支持类，比如collection类，分页类，
除去collection和分页的话，我感觉GORM基本和Eloquent类似，同样有表间关系，软删除等，当然，我的项目表间关系和软删除用的非常多，其他功能关注不多，也没注意。
至于具体选哪个，你自己测试一下好了。
延伸阅读：
二、resultMap 知识点
resultMap 元素用来描述如何将结果集映射到 Java 对象，使用 resultMap 对列表展示所需的必要字段来进行自动映射，特别是当数据库的字段名和实体类 POJO 中的属性名不一致的情况下，比如角色名称，字段名/列名 column 是 roleName，而 User 对象的属性名则为 userRoleName ，此时就需要做映射。
resultMap 元素的属性值和子节点
id 属性：少数标识，此 id 值用于 select 元素 resultMap 属性的引用。
type 属性：表示该 resultMap 的映射结果类型。
result 子节点：用于标识一些简单属性，其中 column 属性表示从数据库中查询的字段名或别名， property 属性则表示查询出来的字段对应的值赋给实体对象的哪个属性。
说明：MyBatis 中在对查询进行 select 映射的时候，返回类型可以用 resultType 也可以用 resultMap ，resultType和 resultMap 有一定关联和区别，应用场景也不同。
