很中肯的评价，不过话说开惯了 BMW 的人可能都会觉得其他车方向盘很轻

干啥不直接找个 webdav 的 npm 库呢，我刚刚就做了一个跟楼主类似的，完全不用自己去写协议部分，只需要搞定文件系统到 R2 的适配就可以了

这个电视估计不支持 HDR 了

楼主你用错了吧，ID Token 这个 token 是不能用来访问 api 的，只是用来返回用户信息的； 调用 api 的仍然是 access token ，而它是的有效期是很短期的；

楼主说的这些好多没用上的就不给建议了，但是空调的话是有发言权的，就格力吧，不要考虑别的

看了原文，挺好的，楼主可以再加个 kimi 的测试一下，它有一个原生 JSON Mode 的功能

设置里面可以去掉在任务栏的显示

exec format err 这个就是典型的架构不匹配的错误提示

alist 挂载天翼云，然后搞个 infuse ，在 atv 上看，目前我就是这个干的，12T 的高清资源，在家庭影院上看

没几个人理解楼主的问题。。。

把 session 加密存在 cookie 中的目的是实现 SNA 架构（ shared nothing architecture ），这样服务器端部署的时候可以方便的做多副本部署，因为 session 不存储在每个副本的节点中，也不存在某个统一的集中式存储（例如 redis 或者数据库），不用去处理传统的 session sticky 和 session 复制的问题。 每次服务器接收到一个请求时，是从 cookie 中解密得到 session 值，这样前后两次请求是哪台服务器处理的就不重要了； laravel 我不知道，但是 Rails 在很久以前就这么干了。

之所以要加密是因为两方面的原因，一方面是要防止客户端篡改数据，另一方面是 session 这个设计中是可以存一些敏感数据的。 有人认为加密这个方式可能存在客户端破解的风险，但是实际来看没啥问题（这点 Rails 的文档中有说明过）。
jwt 的设计初衷不同，jwt 中的 payload 对客户端是透明的，所以 jwt 一般不在里面存敏感数据；当然 jwt 也采用了签名验证的机制来防止篡改。

至于刷新时间问题，jwt 因为设计的默认是无状态的机制，一旦签发了就不可撤销，它的生命周期不受服务器控制，所以为了避免泄露后被复用，就让 access token 尽可能短（一般几分钟），而 refresh token 就相对时间长一些，但是它智能用来获取 access token ，不能干别的。 而加密的 session 因为不存在一个服务器端状态来维护它的时间有效性，只好每次使用的时候刷新一下。

@yodhcn

三线育儿嫂要七八千么？ 我们家娃也是从小就是阿姨一个人带的，运气还好，阿姨还不错

这个场景应该优先时序库吧

但是昨天晚上我遇到诡异的事了，我从美区帐号切换到国区后（不是卡 bug 那种），app store 和 apple music 竟然都还在，apple music 点进去，是我国区帐号的数据，只是进入播放一个音乐的时候失败（能看歌词，但是无法播放）；我重新切换测试了几遍是一样的，设备休眠之后再试还是这样

我都单排，目前百星还差 120 颗星

一个超过 18 年的 java 人在写代码间隙来本帖路过了一下