被 go 语言的 json.Marshal 恶心到了

@pkoukk 遇到过这个包在弱类型解析时有精度丢失的情况

我猜想要的效果是这样的:
```python
import pymysql
import pymysql.cursors


connect = pymysql.connect(
host="example.com", port=3306, user="user", password="password", database="database_name",
cursorclass=pymysql.cursors.DictCursor,
)
with connect.cursor() as cursor:
cursor.execute(
"""select * from users limit %(param_limit)s""",
args={"param_limit": 2}
)
results = cursor.fetchall()
print(results)
# [
# {'id': 13, 'birthday': datetime.date(1900, 1, 1), 'create_time': datetime.datetime(2020, 9, 3, 16, 56, 39)},
# {'id': 39, 'birthday': datetime.date(1900, 1, 1), 'create_time': datetime.datetime(2020, 9, 14, 17, 5, 1)}
# ]
```

@qW7bo2FbzbC0

func TestMy(t *testing.T) {
db, err := sql.Open("mysql", "root:123@/test")
if err != nil {
t.Fatal(err)
}
defer db.Close()

rows, err := db.Query("SELECT id FROM t1")
if err != nil {
t.Fatal(err)
}

for rows.Next() {
var id any
if err := rows.Scan(&id); err != nil {
t.Fatal(err)
}
m := map[string]any{
"value": id,
}
b, err := json.Marshal(m)
if err != nil {
t.Fatal(err)
}
t.Log(string(b))
}
if err := rows.Err(); err != nil {
t.Fatal(err)
}
}

{"value":1}


用 any 接收数据，返回的类型由驱动实现决定，database/sql 只提供接口，驱动负责返回 sqldriver.Value ，所以真不是 Go 语言的问题。

go 的语法很怪异

这跟 json 都没有关系，而是 sql 类型和 go 类型之间的转换问题。

@vczyh 你这个是什么驱动？

@qW7bo2FbzbC0
github.com/go-sql-driver/mysq

@qW7bo2FbzbC0

github.com/go-sql-driver/mysql

@james122333
1. orm 是非常不好的选择, 中小项目倒是还可以, 大项目大数据量的, 用 orm 存在一些不确定性可能导致性能风险, 所以我都是禁止团队试用 golang orm 的
2. 还有生成代码的 sqlc 这种, 性能当然是最友好但用起来也有点麻烦, 因为一些业务是上下文比较复杂的, 单纯生成一段 sql 对应的 go 代码还需要 ctrl cv 而且还要修改对应的地方, 功能修改的时候比较麻烦
3. sqlx 简化了一些 binding, 但也把一些简单的复杂化了, 比如又有 Select 又有 Get, 比如 Insert 缺少 struct 的自动绑定(我没深入使用只是看它文档和例子), 综合下来我觉得它少了一些可以真正节约体力的但多了不少没必要的, 所以对我来说病不好用

所以以前还是继续标准库 raw sql, 直到我实在忍不了标准库 raw sql 自己搞了这个

@qW7bo2FbzbC0 #37 没看到别人扣帽子，反而是你自己情绪化，人家都说了你用不惯 go 就换成你喜欢的语言好了，再说了，interface 满天飞就是犯懒的行为。

@lifei6671 1.8 之前还有什么办法避免 Interface 满天飞？

@james122333 我这个就是简简单单几点:
1. 鼓励明确定义 table 对应的 struct, 用明确定义的 struct 操作 sql, 这个 struct 自己手写也好用工具生成也好, 都挺方便的
2. 鼓励 raw sql, 避免 orm 之类的可能生成了性能不友好的语句造成性能事故
3. 框架尽量自动映射/绑定 sql table 和 struct, insert/update/select 这些与 struct 映射绑定操作密切的都很轻松用 struct 操作
4. 奥卡姆剃刀原则, 不提供 orm, 不提供那么多没什么必要的垃圾接口

@qW7bo2FbzbC0 "我觉得 go/sql 和 json.Marshal 对于匿名类型查询不友好也是犯懒？"
不友好的意思是指不能用方便又稳定的办法解决这个问题,只能用麻烦但是稳定的方式解决.
你认为这不友好难道不是犯懒吗?
BTW,何必这么敏感,犯懒又不是什么攻击性的词语,我自己也经常犯懒,人皆是如此,只是要可能会付出代价
这个世界还是挺美好的,没必要一进入互联网就进入攻击模式

@zxdstyle 你想表达的是动态语言和静态语言的区别

@fregie 犯懒字面上是贬义词吧，你觉得不是攻击性的，那你可以自己多读几遍，不要替别人做决定。稳定不稳定不知道，写起来麻烦的代码后面维护起来肯定更麻烦

@qW7bo2FbzbC0 #71
interface 满天飞是当时写这些垃圾代码的人的问题, 不是 golang 自己的问题.
正确姿势本来就应该避免 interface 满天飞, 我看到很多喜欢搞 interface 满天飞的, 是 php nodejs 之类的转 go 的人居多, 这也不能全怪他们, 毕竟以前语言习惯已经信手拈来了, 刚开始未必能意识到这样会带来工程上的问题, 更何况有时候赶工只追求先搞定业务
c/cpp 或者一些新手上路就是 go 的, 姿势正常的人多些

接手别人的屎山不是 OP 的错, interface 满天飞不是 golang 的错, OP 要怪就都怪写屎山的人吧

用 ScanType 反射？

用 go 千万不要和别的语音比 不要之前语言思维定势。不然坑还更多

按楼上说的 json.RawMessage 解决了，我没有想到要去 json 命名空间里找类型
@leonshaw

@qW7bo2FbzbC0

这你要问 driver 为什么输出的格式是[]byte 也就是你上面贴的那个 lib
目前没时间研究 你自立自强点
至於 json 对[]byte 处理是合理的