取决于具体的应用场景，单纯的从技术角度来看的话，不一致可能确实是一个问题，但是更多的时候往往是我们自己想多了。

当业务和技术架构不匹配的时候，及时调整技术方案才是首要的，例如是否有必要使用微服务？或者服务之间的职责划分是否合理？

在没有具体的应用场景上去讨论合理性就是 XY 问题。

@lopssh https://app.diagrams.net ，旧称 draw.io

画了一张图，凑合看吧

https://i.imgur.com/DkO4zJw.jpg

https://www.v2ex.com/t/794611
我还是那个问题，当然这个链接的标题是“国内”。

1 、今天合法的东西，明天不合法了，不允许存在于链上，必须要抹杀掉，如何处理？

2 、如果没有成本就能往链上加东西，那岂不是无限膨胀了？所以必然存在一系列限制。

3 、我作为一个节点加入区块链中，有什么好处？

发币同时解决了问题 2 和问题 3 ，需要算力计算，还能得到奖励。问题 1 已经不仅仅是技术问题了，而是你这个东西本质核心是否合法的问题，随时可能会面临被政策抹杀掉的问题。

联盟链能不能解决问题 1 ？能解决那你就不是区块链，只是披着区块链的皮。

去年茅台回本了就退了，如果没有精力去研究的话就是在赌博碰运气了，保持清醒是最重要的。

@SuperMild 思路值得鼓励，希望你可以一直对此保持热情。

我还记得之前 github 收费的时候，就有人尝试使用公开仓库来当作网盘使用，甚至还为此开发除了一套自动化的脚本程序，push/pull 的时候自动本地加密 /解密。使用过程中无感，只需要配置一个密钥即可，当然那个时候的限速还没有现在这么严重。Windows 平台也有很多在驱动层实现的透明加密软件。

所以如果只是想要文件在落地的时候进行加密，防止其他人直接绕过系统得到原始数据，完全可以采用一些比较成熟的方案，而且安全性是比较高的。记得很久以前在学习安全这一块的时候，给我印象最深的一句话就是“不要自己去发明加密系统，除非你是从事这个行业的专家”。

当然了，如果只是为了绕过一些自动化的扫描，也完全可以使用压缩软件+密码的形式。不管做什么，明智的做法应当是尽快找到一种正确的方式好让自己别把时间浪费在本不应该浪费的事情上面。

加密 /解密 ✗

编码 /解码 ✔

一个变量到底存储的是什么？变量类型指明了存储的数据如何使用，对于一个 int 类型的变量来说，存储的就是实际的数字。对于对象来说，存储的就是一个内存地址，它被解释为具体类型在内存中的起始地址加上成员变量类型偏移量。以上这些只是一些表面的解释，编译器或者解释器 /虚拟机会根据这些信息来优化，并最终操作计算机。

所以 final 修饰的是变量值不可改变，而不是这个值再被用来解释翻译，并操作其他内存的数据不可改变。

@qwe520liao 这里说反了，应该是父类指针既可以指向父类实例，也可以指向子类实例。虽然 Java 没有指针的概念，但是这里相当于引用。

根据里氏替换原则，子类实例指向父类指针，也就是说假如有一个 SubUser extends User ，此时 List<User>是可以 add 这个 SubUser 实例的吧。如果想要返回 List<SubUser>，可以把方法签名改为 List<? extends User>。

有没有可能发一个网盘地址呢？ [狗头]

之前在广州城中村住了一段时间，也是房东不让拉网线，但是房东自己的网（ 50 块一个月）延迟高，网速慢，用了一个月之后实在忍不了了。我发现周围的 WIFI 信号特别多，后来就买了一个大功率网卡+定向天线，然后抓握手包跑弱口令，后来发现用万能 WIFI 可以直接获取密码。大概蹭了半年的网，回想起这段经历真是让人感慨。

数据权限一般直接穿透到持久层了，一般的做法是直接给每张表加额外的字段，辅以各种框架的拦截器修改 SQL 来实现的。

当然可以使用一张独立的表来跟踪所有的数据行，无论如何，都会引入额外的复杂性。想想操作系统是如何确定当前用户拥有某一个文件的读写权限呢？类似的，你也需要一种像文件系统的东西来支撑。

所以如果不是所有的数据都有这种数据权限的需求的话，直接按照最简单的来做，也就是针对这些有需要的地方，做专门的代码处理逻辑，理解需求真正想要的是什么。

如果你想直接通过 SQL 来进行匹配，可以使用正则表达式，取决于数据库支持的函数和运算符。不过看来这种元数据不会太多，因此全表扫描也是可以接受的。

可以看一下 Spring 是如何匹配的： https://github.com/spring-projects/spring-framework/blob/main/spring-core/src/main/java/org/springframework/util/AntPathMatcher.java

送人的话，山尔堂的银骏眉，或者他们家的清风红韵金骏眉，价格一两百块一两吧。

悲观锁：

在一个事务内，查询余额使用 SELECT .. FOR UPDATE 获取锁，这样其他事务既无法读取，也无法写入，但是要注意死锁的情况，顺序编排要一致。

乐观锁：

在一个事务内，更新余额使用 UPDATE account SET ..., version = @version + 1 WHERE id = @id AND version = @version ，这样更新失败的话返回的影响行数为 0 ，可以凭此判断是否成功。

如果你的 AccessToken 不是 Stateless 的（意味着每次都要读取状态，校验 AccessToken 的合法性，判断这个 AccessToken 是否已经被撤销，或者是否已经被替换），那么 RefreshToken 就没有太大的意义。

如果你的 AccessToken 不需要读取状态（无论是数据库或者缓存），仅凭 Token 本身的签名信息就能确定它的合法性（如 JWT ），那么 RefreshToken 的存在就相当于有了一个检查点，可以在检查点确认是否还可以续签。

因此 AccessToken 的有效期应当尽量设置短一点，通过 AccessToken 访问，只要通过签名校验合法即可通行，无序读取额外的状态来进一步确认是否撤销，当 AccessToken 过期以后再通过 RefreshToken 读取额外的状态（数据库 /缓存）确认是否继续签发。