cookie 放敏感信息（密码，密文，token，key ），其实都没有问题，问题是明文。
这里的明文是指用户所输入的字符串信息，原封不动地存储在 cookie 中，那么即有可能被泄露。

正确的做法是，前端存储加盐哈希后的密码，这样文本存储在 cookie 中是没有问题的。这里就需要后端登录接口，所接受的密码字段，是哈希后的密码。所以这里后端可能也要背锅。

SSO 和 Oauth 永远混为一谈，再加上各种中文技术博客继续误导……

@zivyou 根本没有办法

@zivyou 请问怎么识别？ User-Agent ？

@YoungBalance 简单来说就是大学计算机专业的课程，上大学的时候总会觉得大学教的东西落后于社会，其实那些都是计算机的基础。现代用到的技术都是从那些基础理论演变而来的。一心想靠学一门编程语言就能找工作，你的能力只能停留在知其然不知其所以然。技术领域变化很快，如果没有理论基础，你很难跟上时代步伐。
出来工作后，和身边的同事都会有同一个感慨，就是大学没有好好读书。

以工作多年以及当过面试官的经验告诉你，把基础打好，对你整个职业生涯都很有帮助。

无论多少钱，电动自行车还是电动自行车，机动车道没有路权。
8000 还不如买台春风，外观酷炫装 B，还能把妹。

如果哪家公司面试应届生，只关心你会不会某种语言，这种公司也劝你不用去了。
招应届生的公司，要么是想培养符合公司价值观的员工（通俗讲，就是希望有更高的忠诚度），要么就是想找个廉价劳动力了。
前者看重你的基础扎不扎实和学习能力，后者就看重你来了能不能马上写代码。

应用场景感觉比较局限 => 其实就是数据库专业化。
LZ 的银弹思维要改变一下。

@ABenmao 你这个场景里的 code 实际上是 error detail，你的程序不会去断言这个 code 做出相应的动作，而是透传到前端。最后由人捕获去排查问题。这种 code 的设计目的和 http 状态码的目的是不同的。这种 code 一般头几位代表系统或服务编号，中间几位代表模块，最后几位可能代表代码行或者顺序码。

@l00t 所谓的错误处理，也就是 error recover，你无非做两件事。
1. 这个是你能处理的错误，记录日志，继续你的逻辑。
2. 这个你不能处理的错误，要么透传，要么收敛。

只有第一种你是需要断言错误的，这种情况十分的少，单靠返回码就能处理的更少，那么额外增加返回码的价值就更少了。

第二种，是你做得最多的，透传就不用说了。收敛的话，以登录接口举例，你可能先查询用户信息，然后验证密码，然后查询权限，等等。你接收到下游返回的错误情况有可能是用户不存在 404，密码错误 406，无权限 403 等等。你会将这些错误收敛为一个 403，并在 msg 中说明是哪一步出错了。

需要自定义返回码，并大量使用的公司，个人觉得有以下可能：
1. 接口定义得“太大”，即参数特别多，例如把登录和退出都做在一个接口里。
2. 不能“有效”地处理错误，大部分人截获到错误后，并没有做 recover 的操作，也没有做收敛的操作，而是转换成另一个他所理解的错误，再返回。这种“扩散”错误的做法，会给系统带来更大的复杂度，降低开发者处理错误的意愿，但带来的收益却很低。
简单来说，就是你给系统增加了 90%的麻烦，去处理你 10%的情况。

每次有人在纠结返回码问题的时候，我就贴出这个链接，然而每次都没有人看。
https://cloud.google.com/apis/design/errors

Google APIs must use the canonical error codes defined by google.rpc.Code. Individual APIs should avoid defining additional error codes, since developers are very unlikely to write logic to handle a large number of error codes. For reference, handling an average of 3 error codes per API call would mean most application logic would just be for error handling, which would not be a good developer experience.

试想想，如果下游服务返回一个错误码给你，你有两个选择
1. 识别并处理这错误码：
if code == some_error_code {
// do something
}
2. 不处理透传返回码:
if code != 0 {
return code
}

第一种，如果你错误码很多，那你就要写大量的错误码处理逻辑（每个接口）
第二种，透传到上层，那上层遇到的错误码可能性就越多，越不想处理。那么错误码的意义在哪里？出错是，方便定位？那一个字符串类型的 error detail 是不是表达能力更强？

自黑是为了与众不同

赞同 #31，听到过有人说，“然后就说明明一个请求搞定的事情，偏偏要转发几次请求”，最后得出结论是微服务没用。
不熟悉业务，不从领域设计出发，就是为了微服务而微服务了。

能不能低调一点？

@stevenbipt #63
1. 水平不足就不写并发代码了？水平不足就可以不解决性能了？不止一次见到有人以水平不足去怪一项技术垃圾了。
2. 即使 Java 的热部署也是有要求的，不是所有更新都能够热部署，以前巨石架构用热部署还情有可原。都 9102 年了，微服务都快淘汰了，还不知道蓝绿部署，滚动发布。go 编写服务，配合容器化+k8s 编排，发布是很轻松的事情。

@upday7 举个例子，搜索。100 万条数据找 10 条匹配度最高的。
一台服务器+一个数据库，基本上瓶颈会出现在数据库，因为你要在 100 万条记录的数据库中寻找 10 条数据。

换个做法，一台服务器，100 个数据库，每个数据库存 1 万条数据，那么一次搜索查询，需要并发出 100 个数据库请求，那么这时候瓶颈就会出现在应用服务器的并发性能上了。

所以 go 要扩大收益，架构也要跟着改变。