看你想解决什么问题
1. 防止中间人攻击，数据安全：直接 https
2. 反抓包：客户端加密可行

SSO 其实很简单，我来尝试解释下，不讲具体协议，就讲一下大致原理和认证过程

先定义下参与方，前后端都接入了 CAS 认证过程：

AppA：*.appa.com
AppB：*.appb.com
CAS：*.cas.com 单点登录用户中心



一个用户进入 AppA ，发现没有登陆，跳转到 CAS 登陆，CAS 登陆以后，在 CAS 域名下保存 cookie ，然后将 cookie 放在 URL 上重定向到 AppA ，AppA 识别到 cookie ，将 cookie 保存到 AppA 域名下，下次就不需要跳转了，直接就是登陆过了。

同一个用户进入 AppB ，发现没有登陆，跳转到 CAS ，CAS 已经有 cookie 了，直接带着 cookie 重定向到 AppB 就可以了。

有好感可以继续，异地这个问题提前解决，先达成一致再进下一步。

一直准备着，有更好的机会就走呗

绩效这东西，就算有明确的规章制度，但是大部分还是由上级决定的
如果和上级合不来，早点走

两个都有锅，我觉得 55 开吧

不过，领导这么说话的公司呆着干嘛

然后，要看几次线上事故的原因是不是类似，反复犯同样的错，自己也需要反思下。

go 的协程也会阻塞系统线程啊

只是 Go 的所有 IO 操作被封装过而已，不会直接调用系统 io

和 Kotlin 的效果是一样的，只是 kotlin 的想要不阻塞系统 thread ，需要调用特定 API 而已

@0xsui #59 见过，想骂人，国外的 quickbooks ，API 查询直接写 SQL 。这可是国外流行的财务软件，母公司市值 1500 亿刀，

搜索
open source ppt online

找到了几个库：revealjs ，Impress.js
等，好像还带了协作功能

半年不太可能实现，web 还需要后端配合，这个也不简单。

@avastms #37 RESTful 最重要的是对业务建模，一个资源对应后端一个业务模型，所以其实是能在大部分场景使用的。只是业务模型和前端 UI 并不完全对应，所以前端的时候一般会都套上一层 BFF 。

1. 公司或者部门有规范，按照公司规范来，没有的话，公司有点问题，没做好
2. 老项目，按已有的 API 规范来
3. 新项目，看项目能不能达成一致使用 RESTful 风格的 API 设计，不能达成一致，使用 RPC 风格的 API 也不是什么问题

当然，面对说 POST 更安全，这种极其不靠谱的后端，可能及时跑路更好

我 17 年的都免费换了

@SuperMild 有了泛型更好玩一点

https://i.imgur.com/cYddxY9.png

作为后端，负责一个 admin 项目，然后收到 dependabot 的提示升级 chore(deps): bump axios from 0.21.1 to 0.21.2 的 PR ，然后 merge 了，然后页面挂了。
一脸懵逼，这兼容性也太差了。

@Joker123456789 写分布式应用的情况下，每个步骤的错误都需要仔细处理的时候就会觉得 try catch 很麻烦。go 的这种错误处理在这种场景下用起来还不错，但是写业务的时候，大部分中间步骤不需要处理，直接抛出，当然 try catch 很爽。
Result + ? 操作符，这两种情况场景处理起来的感觉都不错。

Go 的 error 对应的是 Java 的 checked exception ，和 Rust 的 Result<T, Err> 本质是一样的，只是用起来方不方便而已； Go 的 panic 对应的是 Java 的 runtime exception

@SuperMild 可以兼容已有的库，只要最后一个返回值是 error ，就可以使用 ? 操作符。我知道社区早就讨论过这个方案了，也被拒绝了，在这里只是吐槽下，不能接受 Go Team 拒绝的理由而已。

首先，订单成功这个描述就有点模糊。
成功提交，成功发货，还是成功配送。
建议参考 #17 ，重新定义状态

和泛型一起提出来的方案。。
像 Rust 那样 ? 不好吗
为了不承认自己设计错误，搞的大家的代码看起来那么恶心，写起来也恶心。
真是无语了