这个应付一下领导就行了，技术上实现绝对的安全是不可能的，只要你的 APP 在我的设备上能跑，加不加密都没啥区别，只是时间问题。终端的安全问题不需要考虑在内，https 也只是为了防止中间人。

对我而言，单元测试提高了团队成员的自信，放下了悬在心中的那块石头，不用担心每一次修改是否会破坏某些东西而诚惶诚恐。

事务改善了人们的生活，让我们可以用一个简单的编程模型来屏蔽底层的不确定性，这本身就是一个很伟大想法，但是要善用，很多情况下，问题不在于客观事物本身，而在于人。

看场景吧，一般角色对权限的是配置数据，数据量不大可以做缓存，更新的情况也比较少。甚至可以把角色对权限的这个关系直接通过配置文件存储起来，都不用存数据库。

而用户对角色的这部分数据是动态数据表，适合放到数据库中。话说回来，量变导致质变，不同的量级有不同的做法，条条大路通罗马。有规范的按照规范执行，没有的话按照简单的来做就行了，在没有规范的前提下就不要苛求太多。

那我建议你最好不要把事务放到 business 上面，粒度小会影响性能，如果不考虑用例你将无法预料会被怎样调用，事务边界应该是按照某一个用例来的，而不是按照增删改查这种没有什么语义的偏技术功能性的方法。在我看来 edit 这种就是没有什么业务语义的方法（类似 update ），把它当作了偏底层的 DAO/MAPPER 来用了。

感觉你的 business 上面应该还有一个应用层吧，针对具体的用例封装这些逻辑，每一个方法都是一个独立事务，没必要复用应用层了，相反 business 可以被复用。如果是我的话直接一个 service 可能就结束了，没必要搞复杂，顺手就行了，效率才是最重要的。

目前用的圣手二代，装了个 karabiner-elements 调整键位。

@INCerry 感谢老哥，之前没怎么接触过 C#，看来我还是对 C#语言的生态不太了解，的确如果利用 System.Threading.Channels 和 Task 可以很方便的做一个类似的东西，IO 也可以用你说的管道来实现。

顺便说一句，C#语法真香！

mybatis-plus 用的应该比较多，拓展性和灵活性都不错，不过我个人的话要么用 Hibernate 要么用 JdbcTemplate，读写分离，没必要只用一个东西。

touch bar 真是个没有卵用的东西，还不能关掉，我现在的笔记本休眠一下那里就闪个不停。

SpringBoot 只是一个类似脚手架的东西，我这么说你肯定没有概念。如果你之前没有接触过 Java 后端开发，可能会遇到很多术语名词，理解这些术语本身需要一定的时间，因为往往它们之间还存在嵌套的关系，即你要明白这个概念，还需要深挖理解另一个概念，里面又涉及到了很多，这是我之前学习的时候遇到的最大的障碍，基本上没有速成的方法，必须要靠时间累积。比如包括但不限于 JDBC 、Servlet 、Bean 、POJO 等等，我这里列举的算是最简单的。

如果你有英语阅读能力的话，我建议直接上 Spring 的官网，文档和参考手册都很详细。如果你想从头开始先找一个练练手，我建议直接搞一本国内的 PDF 电子书，跟着上面做一遍，这种书实体的反而不太方便，看完一遍就没啥价值了。虽然版本不一定是最新的，但是起码自己动手做一遍会有一个大概的了解。

问题可能就在这里，很多东西今天是“合法”的，但是明天不一定合法，所以现实情况就是，不允许出现“真实的历史”，因为这些历史可能不利于现在的环境。

个人对区块链的一些理解：
首先是区块链为了解决什么问题？那就是信任问题，或者说历史不可篡改的这个特性。

如果是所谓的“私链”，那么意义何在？我能想到的就是，这个私链对于外界或者对于合作伙伴来说是“可读不可写”的，这样可以起到一个监督的作用，即你不能修改历史数据，你改了我就知道了。

而对于“公链”或者“联盟链”，有限的玩家是可以写入数据的，只要大家都承认你写的数据是合法的。

而对于读和写都只能自己玩的，外界完全感知不到的这种区块链，我认为意义不大，因为篡改了历史别人也不知道。