@Trim21 #2
原来如此，那可能自动化指定版本比较好了，go 发新版了就新跑一次自动化看报错没，报错了 OP 更新兼容性。github action 里指定版本，或者 action 定时任务每天跑一次 go 最新版，有问题了就提示

go 向后兼容，比如 1.18 的 go 兼容 1.17 及更低版本的 go 的代码，并不是说 mod 里你声明了 1.17 就只能用 1.17 ，而应该是最低要求 1.17 的 go ，但是 1.18 也是可以用你的库的，所以你只要用 1.18 的 go 测试你的库 ok 就可以了

如果 OP 的库不是依赖 1.17 相比于低版本 go 新增的新特性，OP 甚至可以考虑把 mod 里指定更低的 go 版本

我只是喜欢 go ，自己实际项目用 go 的占比不是最多所以不敢确定对错，请 OP 实操为准

基于标准库的 echo 比 gin 看着舒服多了，基于 fasthttp 的 fiber 不错

现在这个年纪申请国外硕士润刚好来得及的

@c1273082756
兄弟，我负责任地告诉你：
精油拍背不如啪了再睡

@WilliamYang
这是我买了几万元书的新的：
一般歪果仁写的，买得过，尤其老头子们、日本人的书
一般国人写的，我建议谨慎考虑再买，尤其不算年纪大的作者

OP 这本我没读过，简单看目录和用词，内容含金量层次可能比较像 N 天精通系列。
N 天精通系列并不是说内容不可救药，作为入门是可以的，只是进阶不够、所以那个系列书名用“精通”二字显得浮夸、为博眼球营销脸都不要了、不符合技术人应有的特点、是比较让人反感的。
OP 这本书名还算中规中矩、朴实，这便可以算是很厚道的了

用 go 却不用 go style ，你们真是够够的了

我先假定 OP 是指 web 类的服务，在这个基础之上，OP 提出的这个问题本身是错误的，原因：
1. 对于前端：技术模型是有渲染树、数据更新则需要对应的视图更新，换另一个词就是有状态，前端的画面显示是跟数据、状态对应的
2. 对于后端：web 类的服务是无状态的接口为主，一个请求来了，都去查询、写入公共的缓存、数据库即可，每次与缓存、数据库的交互本身就是一个完整的原子流程、只要更新了也就相当于刷新了因为下次或者其他请求也是查缓存数据库，根本就不存在如何刷新的需求

对于其他类型的有状态服务，单进程内你可以简单的发布订阅去实现一个数据更新时自动回调订阅者来实现多个模块及时刷新数据、状态相关的，如果是多进程多服务，队列之类的发布订阅来实现跨进程的数据同步也可以，但如果涉及到并发时序与事务相关的，则需要认真设计、避免因为乱序导致数据不一致的问题

大家评评理，OP 这种说话方式，是不是比我这种尖酸刻薄更讨厌？哈哈哈

比代缴成本高些，但是可以当上 CEO ，建议上车

参考 #9：
v2ex.com/t/863468

学疯狂石头 /赛车里黄渤的口音对他说：小 mei 儿你给额免费按个头，按滴好滴话我考虑一哈买一下
结束了说：小 mei 儿你这个头按滴额不素服哇，下次你给额再按一哈，哪次按素服了我就考虑一哈

或者就说５块钱一瓶得不得行？太贵 dia 我买(二声)不(三声)起(四声)。。。

每次都可以说不素服，事不过三，你看他还给你推荐不

我刚问过大司马，他说 OP 现在还在第一层，哈哈哈

@sky857412
相比非 sql 于业务代码，sql 占比挺小的，而且 ORM 里你看不到 sql 的逻辑。

编程语言排行榜里，sql 甚至还前十呢，排名在 golang 和很多流行的语言前面呢。用 ORM 来对待 sql ，即使是 java 那些很成熟的 ORM ，也让我觉得是对 sql 的侮辱——人家是门语言，你们却像嫖客一样上来对人家一顿胡搞猛搞、连自己做了啥都不知道，然后还说 ORM 真香，真是对自己对 sql 都不负责，妥妥的渣男。。。

@maotao456 正解！ ORM 党多数都是 cv 程序员、性能和服务稳定性啥的都不怎么在乎

@lesismal 可以可以，我以后新项目里试试，这比 ORM 可舒服太多了

建议楼主做好本分，不要干涉女主当家 /手动滑稽

招人帖变招黑帖，只能感叹一声：活该。
不过等抖音上市了，估计又会有很多人羡慕字节家好些人财富自由了。

@root01 手动:dog:
一望二三里，烟村四五家。
楼台六七座，八九十枝花。