steelshadow39

@sumarker #1 八股我觉得也挺看运气，有些面试官就只问一下浅层，有些就会往深追问，如果没有实操经验，一问就完

@thevita 我的需求和您提到的 schedule 定时任务很像，第一次用户手动配置，请求接口，执行扫描任务。然后会设定这个扫描任务定期执行一次，我纠结的就是每次执行如何获取第一次请求中的参数配置。

@vance123 接口参数变的话，就存一个新的请求信息吧，不对原来的做修改

@vance123 我这里的意思是：审计和重放都可以使用存 JSON 这种方式来实现，不是一表两用。确实应该按你说的，分开用，毕竟日志审计和重放还有差别，重放的话，管理模块还需要知道重放哪一条参数，所以我认为重放参数的持久化还要和某些属性关联，比如用户。

@Avn #6 非常感谢，您提到的两种情况我都有涉及，请求体信息（接口地址，时间等）我是准备在网关层持久化的，以便后续审计。但我的业务不像您提到的：必须要有前端显示，它可以理解为一次任务，第一次的任务配置需要用户前端填写，后续的任务执行都可以使用同一套配置。所以任务执行需求和审计需求是否都能用“直接存储 JSON 请求体”的方式满足呢？

如果是的话，每次管理模块调用子模块，就先从库中获取 JSON 请求体，再构造请求调用子模块接口。我还想过另外一种方案：管理模块不直接构造请求调用子模块，而是告诉子模块接口请求参数的存储地址，由子模块自行获取参数执行任务。对于前者，子模块接口接收不同类型的 RequestBody ，比如登录接口接收 LoginBody ，注册接口接收 RegisterBody 。对于后者，子模块接口的接受类型就固定了，都是“参数信息存储地址”。除此之外，我目前还没有想到这两种方式在实际开发中的优劣。

@julyclyde #1 但内部调用实际干活的接口时，还是需要前端 POST 过来的参数

@higker #154 研一，再一年找工作了，研究底层的时间确实不多了，个人发展方向也是后端应用。GraalVM 还有 Java21 新出的 loom ，virtual thread ，这些离普及还很远吧，我觉得公司做一套升级要考虑的太多了，求稳还是保守一些。当然个人可以提前开始学习了

@c2const #41 卷也不算是语言问题，算是社会问题了哈哈

@gitrebase 这个是开发者自身的问题吧