自己实现一个类加载器，加载不同 SDK 的 jar 可行性如何？
就是说把厂商 SDK 的 jar 当做文件资源，不直接通过 gradle 打包，而是使用动态加载的方式载入需要的依赖。

@gbj OK，有值的情况下又不一样了，这个涉及到属性命名策略（ PropertyNamingStrategy ）以及你使用的是什么 JSON 库，如果你使用的是 SpringBoot 默认没有配置的话，那么默认用的是 Jackson，命名策略好像是骆峰式。

你让前端把字段名大小写改一下，或者使用 @JsonProperty 注解你的 VO 字段。

包装类型默认为 null，你这里 Integer 、BigDecimal 因为没有默认值，所以这个结果是符合预期的。

@GGGG430
1 、NULL 值并没有比空字符串占用更多的空间，反倒是如果一个列本身用 NULL 是很自然的选择，但是强行给了一个默认值，那么这个默认值反而比 NULL 值所占用的空间更大。
2 、关于索引，如果索引的值本身就很稀疏，那么使用默认值来替代 NULL 并不会有什么帮助（ b-tree ）。
3 、还是那句话，取决于使用场景和数据库 /存储引擎，如果明确告诉你使用 NULL 就会有问题，那么这个时候才应该考虑是不是要做此类优化，提前优化是万恶之源，而且此类优化效果也是微乎其微的，只是它的不利影响被放大了。

数据库 /存储引擎有很多选择，版本也有很多，很多网上的奇淫技巧只针对于特定的版本有效，没有必要纠结在这些小问题上，国内很多公众号、技术文章现在基本上都是广告居多，颇有点中医理论的味道。

的确是有很多公司用统一的包装体来返回所有的数据，我个人认为这是没有必要的。
首先，在成功的情况下，code 和 message 是没有意义的，前端也只会取里面的 body 字段。
其次，在失败的情况下，body 字段一般都为 null 。
就先前面几位说的，如果在失败的情况下不使用 HTTP 4XX 状态码，而全部使用 200，对外部的监控 /采集系统来说也确实不太标准。
所以这个包装体在成功或者失败的情况下都存在冗余字段。
我们目前对于成功的请求（ 2XX ），只返回数据本身，不同的接口直接返回不同的数据。
失败的情况下才会返回统一的错误数据结构，比如 code 、message 。

NULL 值会影响索引？关于这一点我觉得还是要看场景，如果仅仅只是用空字符串或者 0 来替代 NULL 值，我觉得是没有必要的。也取决于用的什么数据库 /存储引擎。

+1 给自己洗脑，不要尝试通过意志力或者自制力，这样会很痛苦，而且大概率经受不住诱惑。
粗略认知到一件事情的好坏还不足以影响情感大脑对一件事情的进行彻底的反思，除非遇到重大转折点。
那么有没有一种没有痛苦的戒除不良习惯的好方法？
答案是有！
《暗时间》里面说，习惯之所以难以改变，是因为它是自我巩固的，越用越强，越强越用。能够从容的改变既有的习惯，靠的不是意志力或者自制力，而是知识。
《这本书可以帮助你戒烟》则是比较针对性的给你洗脑，值得一试。

这里面涉及到太多的内容了，楼主如果实在想要了解的话推荐一本书《数据密集型应用系统设计》。书本身的内容简单易懂，并且引用了大量的文献资料以便深入阅读。

也许在客户家里装个监控摄像头更合理一些。[狗头]

前端实现就是把整个 dom 转换为图片吧，有一个库叫做 dom-to-image，然后上传到服务器。
如果想要后端实现的话，想一下，一个网页的构成为 HTML+CSS，这意味着你要在服务器上面渲染一个页面，包括同步客户端上的操作（跟客户端保持一致），很难想象为什么要这样做。后端一般只是单纯的记录日志，比如用户点了啥，这种活动追踪只记录相关的日志信息比较好实现。

我目前用的 frp，需要配置手动写配置文件，暂时没有遇到什么问题。nps 没有测试过，不过看介绍优点是可以动态管理配置信息不需要重启服务，两个都是 go 写的，部署也比较方便。

不过你这个几千个节点建议还是自己测试一下才能知道最后的结果是啥，转发服务器的带宽配置也需要考虑。

分两部分看：
密码一般不可逆，我们也没有必要逆向出密码的明文，因此属于哈希类的，只需要通过相同的哈希算法得出一致的结果就行，不关心它的明文到底是什么。

但是手机号等这类信息是需要可逆的，也就是加密之后还得解密，落地存储到数据库的时候到底要不要对此类信息进行加密，我记得三级等保是需要的，但是加密的一个后果就是无法支持区间条件查询，比如一个需求是查询所有以 188 开头手机号的所有记录，加密以后就无法进行范围匹配查询了，当然了，也可以有其他的辅助性的索引支撑，但是复杂性也会随之提高。

我又要唠叨一下了，没有绝对的安全，只能尽量保证在泄露数据之后，使泄露出去的那一部分无法单独得出有意义的结果，比如只是数据库被脱库了，但是没有应用代码的逻辑，即使拿到那一部分数据也是没有意义的。当然了，如果你的应用代码和数据库全被扒了，那么再好的加密措施也会变得没有意义，就看对方是否愿意花时间在这上面研究了。

在同步编程模型下直接通过本地线程变量获取绑定的信息，相当于在这个线程上下文中设定了全局变量。

使用同步编程模型，如果在 service 里面获取当前的信息，就跟使用 service 的环境耦合了（本地线程变量），service 不是无状态的。

当然如果一直使用这种同步编程模型是没什么问题的，但如果想要在异步环境下不改变代码也可以使用 service 的话，就必须要在执行阶段先进行类似环境绑定的操作。

比如在执行前，将之前的全局变量绑定到当前的线程，执行完以后再清除避免下一个执行任务获取到错误的信息。

@zhilincom 硬编码拼接除非字符串这些是固定可预期的值，否则会出现像 SQL 注入的那样，破坏了 JSON 的结构。另外，反过来想，与其调用 toString 返回 JSON 字符串，为什么不直接把对象传给 JSON 序列化器呢？

例如：JSON.stringify(obj)

跟楼主一样，从前端转后端，我大概是 2017 年的时候转过来的，在此之前我是做游戏客户端的，用过 Cocos2dx 和 Unity 。

下定决心刚转过来的时候确实比较难，很多概念知识都不会，知识体系明显不足，老实说我刚开始用 Spring 的时候就是用的 SpringBoot，甚至连控制反转、依赖注入、AOP 这些概念都不清楚，更别说如何用好 Spring 了。

在国内做后端肯定离不开数据库操作，对数据库也不熟，老实说我以前上大学的时候报了个培训班，学的是 C#和 SQL SERVER，出来就没用过，还花了好几万块钱。

当时项目上需要，我就用的 JPA，一开始不会用，性能效率一团糟。后来慢慢积累了一些知识，改用 MyBatis，再后来直到现在，我又用回了 JPA，原因就是有自动化的东西为什么要手动呢？说到底框架是没问题的，不管是 MyBatis 还是 Hibernate，关键是如何正确的使用好它。

学会后端之后我安心了，相比于之前做前端给我感觉是，吃了这顿没下顿，心总是悬着的，也正是因为这种不安，驱使我学习了后端。

PS：我现在仍然会做前端，比如 React 、Vue 不敢说精通，起码做工程是完全没问题的。回想起做游戏那段时间，996 算什么？你们怕不是没见过周一去公司上班，周六深夜才下班回家，一周中日夜交替睡在公司的行军床上。

看书要想记着点东西就需要自己阅读过后有一个总结，有自己的思考。
虽然不至于像我们以前读书的时候那样，学完东西还要考试，所以关键还是在于你看书的目的是啥？

而且读不同的书也有不同的读法，像楼主你提到的这种书专业性都比较强，如果不是带着苦思于如何解决问题的目的去看的话，一般了解其中的概念就差不多啦，细的东西等真正用到的时候再查不迟。

看，总比不看强，打开书本就成功了一半。

@hiphopluda 有方法打开，不过需要一些特别的技术，这些技术我相信圈内人士都应该明白。

很久以前看过一本书，叫做《暗时间》，上面说的是：
我们想要自律其实就是改变习惯，但是改变习惯不能靠意志力或者自制力，而是靠知识，让自己真正的接受某一个现实。
习惯之所以难以改变，是因为它是自我巩固的，越用越强，越强越用。

个人认为算法的目的在于，提高计算机的处理效率，在时间复杂度和空间复杂度之间做权衡。

那么首先得搞明白计算机的体系架构，比如搞数据库的，就要考虑到在传统机械硬盘的固有缺陷下如何更好的提升吞吐量。

很多时候我们并不需要去关心如此底层的东西，计算机发展到现在基本上所遇到的问题都有的相应的解决方案，各类编程语言也有相应的库供我们直接使用，我认为学会 Google 比什么都强。