mgcnrx11

minio 官方建议它的存储期待的是高性能的存储设备，不应该是分布式存储不要做什么存储校验之类的事情影响性能，因为 minio 都会给你考虑好了，就不要它来做一层数据校验，你的底层存储又来做一层数据校验。

所以，它设计会希望它的存储就是使用到直接存储物理设备，从而提出 direct pv 这个 csi 。

而 local-path-provisioner 是在一个已经格式化、并挂载到目录下后而使用的，它需要指定一个目录路径就好

direct pv 直接磁盘，只要分区就能用了吧

2.7.18

@Nosub 赞同。特别是最后一句，我看到这种问题都要上 mq 都血压上升

同遇到，没有售后，买新的底座还不通用，底拆掉重新钻孔安装新的底座。最后找咸鱼买回同款。哎...

我发觉，装了行车记录仪。每逢生气上头就把纪录保存下来，同时想着回家就去导出视频举报，那气就能消散不少

https://docs.volta.sh/advanced/pnpm volta 不是对 pnpm 支持不算完善吗？是 pnpm 喔？ volta 用 pnpm 的影响有点大啊

在使用 nvm 管理 nodejs 的版本之后，会发现 包管理器 的版本用 corepack 来做管理就会出现问题。在用 nvm 之后，npm 的版本会跟随 nodejs 版本切换而切换，但是 corepack 安装的 pnpm 缺无法自动切换了。

导致的结果是可能会用上了不兼容的 nodejs 和 pnpm 版本。不知道有什么好的实践方式？

能想到的是通过环境变量 COREPACK_HOME 来隔离不同的 corepack 安装路径

在很久很久以前的互联网上，前后端还是不分离的。浏览器显示的网页，都是通过后端的模版技术动态渲染成 HTML ，返回给浏览器的。那时候还没有 Ajax 的流行，浏览器要做的操作，都得一次一次的请求后端，后端返回一个完整的 HTML 页面来显示结果。

在这个背景之下，HTTP 协议又不支持保持会话。那后端怎么知道多个请求之间的联系？例如某个用户先执行操作 A ，然后执行了 B 。所以，需要一种“保持用户状态”的机制，在后端能保存用户的状态使得后端知道用户执行了哪些操作，又能为这些操作保存一些信息。这个就是 Session 会话了。本质上，它是设计出来“保持用户状态”的。

后来，Ajax 使得异步刷新页面，以及后来大前端的流行，各自新的标准和浏览器技术涌现出来。使得我们有更多的方法来做到类似“保持用户状态”的效果。例如，我们可以把用户的状态保存在浏览器端的 Storage 里面。这时候，就会显得后端 Session 来保持用户状态，没有以前那么必要了。当然，也有很多场景会需要在后端保持用户状态。

那么，在不怎么需要后端 Session 来保持用户状态的场景，后端就不需要为用户专门开辟一个区域来存储，它只需要去知道这个请求是否合法的访问就足够了。所以，开始使用了 token 。

所以，session 会在每次访问后，重新刷新 session 的有效期。因为他需要持续保持会话，只要用户一天不离开，会话都需要继续持续下去。某种程度来说，这个有效期时间也可以当成是某个“用户状态”的数据。

另一方面，在使用 token 时，它仅用于判断请求是否合法访问，没有说要用来保持用户状态的。那就很自然的不会去保持用户状态。所以就是一种固定的有效期。不会像会话的场景一样自动延长。也就是只能手动的通过 refresh_token 来延长。

上面说了这么多，都没有提到 cookie 。我理解的是，用不用 cookie 其实都不影响理解 session 和 token 的一些区别。我不能把 token 放在 cookie 吗？我不能把 sessionid 放在 header 用吗？只是没有这个用的习惯而已。