@kuanat 非常感谢，感觉给我了很大的启发。特别是使用 ctx 的方式去记录复杂的一些数据结构，感觉是个不错的思路

@dreampuf 嗯，谢谢了，我看看第二个库满足不满足我的需求。我也觉得记录 fmt.Errorf 这种逻辑栈记录下来好像也够了

@hailaz 谢谢啦，一会去看看

@me1onsoda 这跟 java 与 go 好像没任何关系吧？你在业务处理的时候不记日志？既然记了日志，就会有碰到相关问题吧，函数调用链长，我的 err 的日志记在哪里合适

之前公司的前端是对参数做 aes 加密，后端解密，只是相对破解门槛较高而已。还有密码应该要加密也不会用 md5 这种不可逆的方式吧，不然密码规则后端怎么校验

1. 接口原子性没太明白，如果是数据库操作的原子性的话，就是开启事务。如果是接口的，那加个分布式锁？
2. tx 一般在 service 层有个接口实现在 ctx 中注入 orm ，接口的实现在 repo 层，一般就如下使用方式：
```
type Transaction interface {
TX(ctx context.Context, fn func(ctx context.Context) error) error
}

func (d *Repo) TX(ctx context.Context, fn func(ctx context.Context) error) error {
return d.db.Transaction(func(tx *gorm.DB) (err error) {
defer func() {
if e := recover(); e != nil {
err = fmt.Errorf("%#v", e)
// log
}
}()
ctx = context.WithValue(ctx, contextTxKey{}, tx)
err = fn(ctx)
return err
})
}

```
service 层调用各 repo：
```

s.tm.TX(ctx, func(ctx context.Context) error {
if err := s.Repo1.Create(ctx, ...); err != nil{
return err
}
return nil
})
```
3. 个人会封装一层，用于常规的 curd 实现，然后各个 dao 不通用的部分单独写

用户名：github_8621

联通畅游卡，29 元 135G+100 分钟通话
8 元流量王套餐用于保号，好像是 30 分钟通话+200M 流量
之前是 5 元的保号套餐，小天神卡。

@Zys2017 直接找客服转，打电话或者 app 或者公众号人工客服，都可以转的

联通畅游卡，29 块钱，135G + 100 分钟通话，联通官方有这个套餐，如果是浙江省内卡还可以老用户直接转。但有合约，2 年合约，合约结束不取消会自动享受优惠

有房有车，还有现金流 300W ，难道躺平不够么？还有啥好焦虑的，光 300W 存余额宝，一年也可以 6-7w 吧，更何况现在工作又没丢

大多数考核都是看领导的喜好，上面跟谁关系好就给谁打高分。
而且每个人做的业务不一样，有的业务产出明显，有的业务重调研，产出效果一般。
每个人职级与工资不一样，这是一个重要的维度其实，但好多可能都放在一起去考核。
所以有这么多不确定因素在，这绩效大多数还是形同虚设，最后还是变成领导喜好去打

红利也不是每个人都能吃到，在红利期间，没多跳，就吃不到。还有买房，没有格局的也没吃到。每个人都以为时间倒退多少年，就能吃尽那个时代的红利，但有没有想过，你是在知道结果的时候去回看的，不是身处在那个时代的人。如果你和马云马化腾一个时代，你就能和他们达到一样的成就么？

最后一天

所以这种小件是有相关的旗舰店还是啥，怎么筛选靠谱的店？ 去年疫情放开，在 pdd 上买了温度计，结果温度计都上不了 36 度...坑得很

如果要使用 markdown ，把 confluence 给排除了，那个 markdown 插件很难用，而且样式很难看

@xiaomada 嗯，好的，非常感谢，我去体验一下你上面说的一些 idaas 产品，加深一下相关概念的理解。

@xiaomada id_token 按你的说法，只用于解析出来 userId ，如果子系统 user 表不存在，则写入到 user 表，然后子系统自己想怎么处理系统会话，它自行处理，其实这时候已经与 id_token 就无关了？ 还有 id_token 与 access_token 的区别在于本身包含了用户的一些信息，但 access_token 如果需要获取用户信息的话，还需要通过 userinfo endpoint 去获取一次，如果本身不介意再去获取一次的话，其实可能就不需要 id_token 了？我这样理解对么？

@xiaomada 谢谢，不同域名下的实现方式对我很有帮助。对于单点登录与登出，oidc 的 core 协议里确实没有，但有几个补充协议，好像通过前端通道实现的方式和你下面说的不在同一个域名下的实现方式很类似，就是需要 iframe 去做辅助同步通知到其他域。

基于 oidc 协议的，最后返回的 id_token ，我在想，如果使用传统的 cookie + session 的方式，那他协议返回的 id_token 到底怎么使用呢？看了一些开源的基于 oidc 协议作身份认证的产品，在应用的实现范例大多数是怎么通过授权码去获取到 id_token 这些，就点到为止了