另外就是，实践上，Refresh Token 也必须接受更严格的安全审计，甚至可能需要使用单棘轮之类的技巧来提高安全性

举例这里粘贴一下《 OAuth 2.0 授权框架》中对角色的定义：

> resource owner
> An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.
> resource server
> The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
> client
> An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).
> authorization server
> The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

抛开 RO 不谈，RS Client(UA) AS 是三个不同的角色，refresh token 是不应该提供给 RS 的

还有一个原因，刷新 token 和认证 token 未必是供同一方读取的。在一个职责完全分离的体系里，AS(认证服务器)和 RS(资源服务器)未必具有同样的安全基线，甚至未必是由同一实体控制。很显然，无限期有效的令牌必须不能被 UA(用户代理——客户端)和 AS 以外的第三者读取，否则角色就要混同了。

时间有效表达范围：-2^48~2^48-1 年，精度纳秒，足以装下 time/Time 的表达范围，但这超出了 int64 可表达的 UNIX 时间戳范围，超出范围的情况可以通过 TemporalValue 的 overflow 探测到。

tortoisegit 虽然丑了点，但这是少数把 git 功能做全做好了的。至于丑，它只是原生 UI 罢了，可访问性恐怕是这些里最好的。

降本增效和屎山堆积相辅相成，裁大动脉点个火，知道坑的人不在了，新来个人把系统弄炸了这是常态

可以积极借鉴其它语言的标准库设计，特别是那些有丰富标准库经验的。

按账户来的，不知道看不看账单地址。
用了下我觉得还行，至少在生成 git commit message 上还是可以的。缺点就是额度有点少，没法敞开了用。

这个和社会分配问题不同，

@moudy
> 每个符号都 tm 可能是别的意思

重载就是用来改变符号含义的，保证它不违反大多数人的直觉是编程者的责任。

语言语言功能很明显应该由使用者保证没有反直觉的情况，保证不了你就不该去用。别人也没义务为了照顾你看不懂而被迫用某种不自然的方式写代码。

@aieruishi fpm 好像一直带缓存吧🤔

取决于你的设计，Go 对这个看上去没有强烈观点，因为标准库两种选择都有。

目前 Temporal LocalDate LocalTime LocalDateTime 已完成，数据库支持已测试 PostgreSQL/MySQL 。
下一步将补充 ZonedDateTime 和 Duration 。

@lysShub 因为 Go 必须考虑零值。因为 Go 的 struct 默认填充 0 。

另外就是 Go 标准库有个很扭曲的设计，我倾向于是设计者忘了这件事。Weekday 中 0=Sunday ，而 Month 则是 0=无效值

@RedisMasterNode civil 这个可以考虑，但是和 carbon 那种思路并不相同。所以选择干脆按照 JSR-310 开新的项目，一些取舍也不必纠结，比如隔壁贴讨论的 MinusMonth 语义什么的。

@RedisMasterNode 标准库没有，civil 有但是不全，不过勉强能用。carbon 看上去有，但实际上不一样的。

@RedisMasterNode 看了下 carbon ，确实很完善，但是缺了一些点刚好 JSR-310 的东西可以补上，所以就弄了。