SSang

直接服务器上虚拟化呗，都会折腾服务器了，干嘛还玩成品 NAS 设备

回来看了一下，发现我表述有点乱，导致跑题了，总结几点吧

1. 还是不要试图用 JWT 来颁发长期令牌了，安全问题 JWT 这种无状态的 token 本来就没法解决。

2. 长期甚至永久令牌本身就有其使用场景，没必要考虑长期令牌的不安全这个问题，真要说的话长期密码更不安全，但我们不也一直在用吗，作为服务提供商，应该是要考虑如何保证长期令牌的安全。

3. 本贴讨论的主要是自动化身份认证，所以需要人为介入的都不在讨论范围（比如要登录，要用户输入密码，要用户确认等）

4. 本帖讨论的为身份认证，上面 nothingistrue 把身份认证拆分成了登录认证和后续认证，不是我想问的问题，参考 API Token （就是一步身份认证，没有再分两步了）

5. 感觉大家一直在说 JWT ，但其实我一直就不想用 JWT （参考第一点）
卧铺专票这种就和 JWT 一样，只能用于短期，就不说了，参考第 1 点。

6. 敏感操作也可以不用讨论了，参考第三点，判断操作敏感度这个属于 AuthZ 了

7. nothingistrue 说怎么存储不重要，是因为你把这玩意理解成 authz 了，其实他都还没到 authz ，认证合法性就是 authn ，都不用考虑这个 token 有什么权限，怎么存储关系的是 authn 过程的索引效率问题。（然后 github 令牌丢了可不只是丢脸这么简单，不要只考虑 push 的场景）

8. 然后反驳一下自己的观点：key 用 json 存用户信息和加密 token 没什么意义，效率还低，直接 key 存明文 token ，value 用 json 存用户信息即可（不是 JWT ）。加密 token 只能防止数据库泄漏导致 token 明文泄漏，但权限依然会泄漏，token 明文泄漏对别人来说没有意义，和密码不同。

git reflog


一般我就是按照公司或主站去简单分类，没进分类的会不定时删

我一般会有搞自动策略，然后分文件夹，有时候会想看看各家公司的广告，整理起来会比较方便查看，一般不是非常重复的邮件我不会删

其实下班用最多的是 bash ，hhhh ，一直在搞部署，没怎么写代码

会
上班 go ，下班 go > c++ > html/js/css > c

所以，拿 typora 和 vscode 比，感觉完全没有意义。面向的需求都不一样，况且所说的那几个优势，其实 vscode 也能实现。

所以 typora 最大的优势就是所见即所得，同时 vscode 最大的优势就是纯文本编辑（好像 vscode 也有插件能支持所见即所得）。这完全是需求和个人的编码理念所决定的

我觉得 typora 和 markdown 完全就是两个东西，我认为 typora 非常不符合 markdown 的哲学

在我的观念里，typora 一直就不是个 markdown 编辑器，只是他刚好存储成了 markdown 格式而已。（用 typora 大部分是贪图 markdown 的轻量，又想要像 word 一样控制排版，直接看到最终效果，但这种需求确实普遍存在，这就是 typora 如此火热的原因）

然后回到为什么 typora 不符合 markdown 哲学（或者最初的哲学）的讨论：

#### 1 纯文本的可读性

我们去各种百科里面看 markdown 的介绍，基本上都会说最重要的是__纯文本的可读性__，这种所见即所得的理念，就是放弃了纯文本可读性的，因为你的纯文本可以写的非常的凌乱，反正最终效果是整齐的就好。

我这几年看过的，大部分用 typora 写出来的 md 文件，纯文本的可读性都非常差，有的只是有大量的空行和空格，这种还好，有的会内嵌大量的 html 语法，换行全靠 `<br/>`，还有一堆的特殊字符，一堆的 `&nbsp`，这种拿普通文本编辑器打开就跟一坨屎一样。

还有一点是很多其他编辑器一样会遇到的问题，就是表格不进行格式化，因为现在大部分 md 编辑器都有实时渲染的功能了，很多人就不注重纯文本格式下表格的问题，typora 我记得会自动格式化的，感觉就还好，有些不会自动格式化的，纯文本读起来就很吃力。

#### 2 沉浸式写作

同时 markdown 所强调的沉浸式写作，希望用户不要去关注排版，专注于写作本身。
在实时渲染的模式下，你就必须去关注排版问题，感觉与 md 哲学背道而驰，不过 typora 也有纯文本编辑模式，但用 typora 的应该很少人用这个功能。

还有一点，就是修改困难，当一个文本被渲染成功后，就会在显示上丢失格式编码的信息，想要修改很多时候得用到鼠标，不过最新的版本好像好了很多。