个人非常反对报错吃掉响应体还返回一个错误页的行为，所以即使是后端报了 5XX ，运维控制的网关也不应该这样返回，定位问题都不好定位了。

取决于你对后端的定义了，明显和这位后端大哥没对上。
他的 [后端] ：自己 Java 写的这一亩三分地，别的一概不知
你的 [后端] ：本地发出的 http 请求对端全算后端
实际上看上去像是你和这大哥中间的某个东西出问题了，后端不想说，你也不知道，于是就变成了你俩搁着互相甩锅。

不过啊，这公司的氛围看上去也挺紧张的了，多大点事都能怼起来，这种环境工作可有点累啊

另外在 SQL 出现的那个年代，一票语言在设计时都尝试尽可能贴近英语语法

看看，这就是没有异常机制后，好多 Go 用户说的 [优雅的错误处理] （暴论
------------------
个人的习惯是，除非理由很充分，否则永远不要用 _ 忽略错误。其次已经 err 的就不要 OK 了，大部分 err 都是现场无法处理的，往上抛，视情况决定要不要 wrap 一下加点信息，否则出了问题没法查。除非理由充分，否则永远不要 err 了还按正常流程返回结果，否则大概率会出了问题都不知道。

咦，图片出不来吗 https://imgur.com/bHvrpjq

@CEBBCAT 比如说注释里有错误可以这样 

你当然错了啊，你说人家破盘子就算了，你怼你女朋友干啥，关键是你还知道她不知道这里面咋回事……就不能好好说话吗

早就知道这个问题了，除了那种每次使用前要你输入主密钥或者过一次 Windows Hello 之类的东西，都不安全……
所以个人很反感电脑上运行国产 /其他看着就不太行的软件，Windows 没有对应用程序的隔离，这个问题就没什么办法

要么写代码生成文档，要么写文档生成代码，既写代码又写文档这的确烦人，时间一久就容易代码文档对不上

直接用 field 意味着没有插入逻辑的机会，内部细节被直接暴露出去了。举个例子当你用动态代理时怎么办呢，field 就无法被代理

用 Kotlin 吧，简单来说就是语言没有 property ，但是实际发现没 property 不行，就搞出来了手动 property 的 getter setter

问就 Kotlin

如果数据逻辑复杂，那 SQL 长是没办法的…适当用 CTE ，视图等等特性降低复杂度吧

聚合算出每个用户的权限数量，小于权限总数的用户

没有特殊原因请不要在内存里分页，常规的 curdSQL 并不难，去把 PostgreSQL 文档前几章完整看一遍，有中文的。

@NeroKamin 有些工具不支持调顺序就有点疼

个人经验是实在不行就临时开个视图~~~

没线上权限，只有开发测试权限，真出了问题找运维要，说清楚目的运维会给

反正都一样，go 写就是繁琐，语法糖少，不熟悉容易写出 bug 。Kotlin 就是你得先熟悉了才能写🤣