@pengtdyd 比如说创建资源（订单）的接口，如果不增加额外的 限制，不幂等才正常吧

api 加个 uuid 和时间戳，比较时间范围和 uuid 重复

传统 API 模式的好处是 API 相对固定，查询模式往往派生自 API ，也相对固定，便于实现和优化； graphql 这种会导致查询模式完全由前端传递，后端进行限制和优化难度陡增。想想是手动实现优化与一个 SQL 等价的查询容易还是编写一个通用的查询优化器容易～ dataloader 相对缓解这个问题，但是彻底解决我看够呛

dataloader 也不能解决全部问题，只是粗暴的把 key 聚合起来一次查询而已。整体来看迁移成本太高了，将整个查询控制交给前端，前端给出啥样的查询完全不可控，很容易把后端搞死······

能不打破就别打破，但有时候也没办法

你想好万一出现修改该怎么办就好

正常办法可以窗口查询，以 a 划分窗口保留第一条，歪办法可以调整 SqlMode 然后 group by (MySQL only)。也可以按某种规则聚合主键然后 join

不能完全不会 Java 的，Java 的一些最新语法可以不知道，但是一些底层机制还是要知道一点的，否则容易抓瞎

@codingBug 不是给用户看的也不能乱写啊···

@jfdnet 当名词讲时也没这个意思啊

go 的时间库设计成那个样子不一定是好事，有些场景无法很好的处理。
协程的话，建议你看下 Kotlin 的，和 Go 的轻量级线程不是一类东西，各有各的好处。
typealias 这个确实不错，等泛型实装应该更好一点。
Gin 和 Spring 全家桶不是一种东西啊。
使用多返回值表达错误这从根本上就是裂开的，不比状态码强。（本条个人观点，勿喷）

Gitlab 有说过这个软件零运维部署是可以的吗

不是很能理解为什么 ban 仓库之余还要 ban 账号，不过联想想之前那位破坏了自己仓库结果呗 ban 号的人，也不意外了

不同软件对这几个环境变量的支持程度不一样，有的吃 all ，有的不吃；有的大小写不敏感，有的很敏感······所以保险的方法是同时设定 http_proxy, https_proxy, all_proxy ，如果你有觉得不够可靠，对应的大写也设定一份，我观察的：吃 all 的不是很多

sql 只做数据层面的更基础和通用的业务逻辑就没啥问题

这 sql 没什么问题，你是没见过把文案塞 sql 里，在 SQL 里格式化时间日期的，这才是真的滥用。