@jam1024
我没预料到兄弟你认为 ORM 比 rawsql 难、ORM 比 rawsql 更安全。关于这两点，我的感觉刚好跟你相反。

@pastor #12
其实其他那些 ORM 比较完善的语言，在做那些数据量不大的对性能没啥要求的项目时还可以的，比如学校的管理系统，公司的 OA ，这些通常单表都很小的没啥压力，用习惯了 ORM 的同行开发效率还是蛮高的

@jam1024 #14
比如 http 服务一个 routter handler：
1. 如果是只需要某个特定的表，直接用一些三方工具导出与表结构映射的 struct 拿来直接用就可以了，比如 model.User 结构体或者结构体数组拿来接收 Query 的结果
2. 涉及多表联查的，我们通常 router handler 文件里单独声明 struct 用于接收 rawsql 的字段，其实并不麻烦，而且通常规范点的项目，除了数据库的 model ，c/s 交互也是有规范的协议格式的，所以不管是 json 还是 pb 还是其他、不管是否联查、声明一个结构体这一步多数时候本来就已经存在于流程中了

@mcfog #6
sqlx 我没太用，自己以前主要是使用标准库 rawsql 。sqlx 、gorm 、xorm 也都简单看过他们的文档教程、还是挺复杂的，相比于使用标准库 rawsql ，这些 sql 库学习成本更高、姿势有点多反倒需要去注意更多问题。
sql 的主要操作，就是增删改查，标准库的查询用 Query/QueryRow ，其他的用 Exec ，非常简洁明了，麻烦的地方就在于 Query 相关的 rows 到结果的 Scan 。
sqlw 把遍历 rows 去 Scan 这些省掉了，中间的一堆 if err 也省掉了。使用 rawsql 能让程序员保持对 sql 语句的功能、性能直观和敏感、减少或者避免 ORM 背后行为那些隐藏的细可能导致拼接出来的 sql 不是自己想要的、甚至出其他问题，而且虽然不是 ORM ，但是执行语句与结果映射到结构体一步到位，还是很省力了。

@dorothyREN #7
go 完全避免 if err 是不太现实的，sqlw 帮助去减少了 for rows.Next{ rows.Scan }这些地方的很多 if err 。
另外，很多人对 if err 抱怨，却没去想过，go 这样使用 if err 让他们的代码更健壮了。相比于其他一些语言用异常处理错误，go 把错误、异常各管各的其实更清晰，只是很多人“先入为主”，用习惯了以前的某种姿势或者框架提供的方式、不想去改变成更合理的方式罢了。

@pansongya 混杂是指 sql 和 sqlw 同时？还好吧，sqlw 把 DB 、Stmt 、Tx 这几个都包装了下，使用 db.Prepare/Begin 返回的是 sqlw 的 Stmt/Tx ，Query 相关的写起来就都简单了，我再考虑要不要增加个 Insert 、Update ，怎么设计能保持简单与优雅。

mybatis ，java 和 go 真的是繁冗与简洁的两个典型了，所以我估计不会去模仿任何一个 java 相关的方案了 /手动狗头 。。

顺便推下自己另外两个库，详见旧帖或者我的历史帖：www.v2ex.com/t/794435

@realpg @pastor 二位看下这种可否节省些体力
@jinzhu 也欢迎 gorm 大佬多多交流指导

建议该新闻视频上《抖音》《 ticktok 》

建议该新闻上《今日头条》

PHP 永远活在 PHPER 心中，永垂不朽！

合格的巴氏鲜奶都可以，不只是几家大厂的，有些二三线小城市的小厂甚至口感更好

顺便祝愿蒙牛伊利去死

我也收到过：
https://github.com/lesismal/arpc/issues/32

他们好多营销用的号来 open issue ，过阵子这个号就 ghost 了
他们中间还有一些个人账号也留言来着但是很快就把个人账号的回复删除了

其实如果不是对单个仓库频繁来袭击也还好，毕竟也能帮助排查些安全问题

对于应用服务，internal 可能不是好点子，一旦多个仓库想共用，没法 import 它

越读书越觉得自己会的少，越是好书越觉得作者水平之高是我遥不可及。

二级指针看着挺舒服的

一直持续下去的话，熬走其他老员工，公司就离不开你了

今天挖坟看到了这个三年前的老帖，不由得感叹苹果公司确实是科技之光