说白了就是 garbage in, garbage out

你说的没错： https://github.com/git/git/commit/7fa6b4e7692926d2d07adee1ef8e277157929058#diff-8117edf99fe3ee201b23c8c157a64c95

@mitu9527 对，所以本质上是想要比较客户端会话和服务器会话。

Token 和 Cookie 都只是数据的载体，优缺点没什么大区别。无论是加密 /签名 Cookie 数据，还是往 Cookie 里额外存过期时间，本质上就像楼上那个哥们说的，完善到最后你会发现往 Cookie 里存的就是另一种形式的 JWT 。

啊，第一点里如果你的框架签名或者加密了会话 ID，就和 JWT 没啥区别了 🤷‍♂️

按照附言里的定义，大概比较一下：

1. 客户端可以直接修改 Session 里的会话 ID 来冒充其它人；但客户端没法修改 JWT 里的数据，因为它是签了名的。

2. 客户端可以直接修改 Session 的 Cookie 过期时间（甚至不理会），所以服务器必须自行维护会话过期时间；但客户端没法修改 JWT 里的过期时间，因为它是签了名的，所以服务器不用维护会话过期时间。

3. 服务器可以很方便地主动结束 Session，无需额外设施； Token 如果需要服务器主动回收，则必须自行维护黑名单。

不过对于 Token 在第 3 点 Token 所引入的额外设施，Session 是在第 2 点里引入的，而且 Token 只需追踪服务器主动结束的黑名单，Session 必须则必须为所有已登录用户存一份。

但话还是得说回来，不要重新定义概念，按照正常的定义会更好地理解你想研究的问题。Session 就是会话，你称作 Session 的东西是「基于 Cookie 的服务器会话」，你称作 Token 的东西是「基于 Token 的客户端会话」。Cookie 也可以客户端会话，Token 也可以服务器会话。Cookie 和 Token 是一类东西，Session 是另一类东西。

Token 这个词本身不应该狭隘地理解为某个特定领域 /框架中的含义，计算机科学范畴广泛使用 Token 这个术语，本质上只要是「一段对用户含义不透明的数据」都可以叫 Token 。JWT 既然是 JSON Web Token，那它就是 Token 。

「服务端会话还是客户端会话」与「使用 Cookie 还是 Token 」是正交的，Cookie 和 Token 只是信息的载体，信息是 SessionID 还是完整的 Session 数据其实无所谓。JWT 的优势是有签名，可以防止数据被篡改。

前后端分离一般见到的都是用 Authorization 报头传 JWT 。RESTful API 的话客户端会话比较多，因为好实现、方便 HTTP 缓存、方便 Scale 。

在循环里写 i 的时候，就已经人脑解耦过一次了，我们写的既不是 index 也不是「索引」。

这就像数学一样，x = sin(BAC) 初到我国时会把它换成 甲=sin(丑子寅)，但现在已经没人这么用了，因为一来写起来麻烦，二来交流起来需要翻译一次很麻烦。

@kernel365 证件照一般要求的都是头顶到照片顶部距离多少、人脸宽高占比多少。目前这个算是最小可行版本，就直接根据使用常规前置摄像头的自拍比例来算初始裁剪位置了。

理论上根据人脸特征点检测和抠图结果来定会比较靠谱一些 ╮（╯＿╰）╭

@daen 谢谢～😄

目前确实是不能重新微调的，下一步会考虑使用已有订单的数据直接进入背景选择，或者允许制作时多选背景。

这就类似我家小区地下车库标牌写的「出口」「进口」，然后「进口」的英文写的 import……

我觉得分开比较好，因为 打开相册 和 使用相机 是两种不同的权限。

想起了「海記憶體知己，天涯若比鄰」。

前端过滤用户输入的目的是提高用户体验，后段过滤用户输入的目的是维持业务逻辑正确和安全。

@wangchonglie 该做的还是在做，只是放到了专门的地方。

@wangchonglie 不必让单人接口特殊处理用户是自己的情况（比如权限管理）；客户端也不必额外保存本用户 ID，有 Token 就行； URL 下可以扩展一些只对用户自己有意义的接口。

所有的 /users
单人的 /users/:user_id
自己的 /user

只安装 Build Tools 就行