是不太好用，不过作者还挺热心

可能是你的后端项目用了一些基于 nodejs 工具链，我记得有个规范 git 提交记录的工具就是.

找个后管理的前端框架改，类似这种 https://vvbin.cn/next/#/login?redirect=/dashboard

我用的 TL-IPC44AW ，可以连群晖

最后面有个报错，疑似你的应用层拿到了一个已经关闭的连接来执行查询，至于 Why 就不知道了

让你形成自我审查的思维，下一次，你在点“发送”前就会三思，“算了还是不发了”

A 的想法也正常，你维护的 lib 升级了新版，应该有一种机制让使用方知道改动了什么，升还是降自己看着办。从你的描述看应该是 B 有新需求导致升级，那这跟应该没关系才对，所以没理由让别人跟着升级

春天到了，万物复苏 大草原又到了动物们交配的季节。

jna 跨平台动态库加载实现是这样的：它加载动态库时，先判断当前环境，然后把 jar 包里面的动态库保存到临时目录，最后再通过绝对路径加载动态库。
都是 java ，可抄

下载写作利器语雀，领会员

邀请码：EN84F0

打开语雀 App ，进入 [我] - [活动福利] - [输入邀请码] ，领取会员

App 下载地址： https://www.yuque.com/download

@FranzKafka95 搞半天你才是服务使用方，你自己开发一个代理层，它在根据需求加载同厂家的 so ，把 so 的句柄，和函数指针保存起来，你自己应用不直接调用厂商的 so ，而是通过这个代理来调用。

一个 so ，两份头文件分别给两家厂商。你这个场景我看着像提供两份特供 SDK ，不是别人来适配你们。。

感觉你说的这个场景就是 spring security oauth 的应用场景，其中 client_user 对应 client authentication ，有很对开源项目可以借鉴，比如 https://github.com/pig-mesh/pig

曾经在生产环境发生过程序崩溃问题，代码审查怎么也找不到可疑代码，崩溃转储出来的内存分析验尸也找不到导致问题的原因。

最后实在没办法了跟甲方摊牌，对方同意直接在 debugger 里面跑程序，这才把 bug 给灭了

@masterclock 调研过，不能直接用，前面我解释过了。这些东西我是很愿意使用，但是在国内一些行业里面，国外的东西就是"水土不服"，无奈。

@PHPer233 这个不行，一来程序要无人启动，再就是命令行参数是可以通过进程管理器看到的(至少 windows 系统是这样)，等同于明文。

@janus77 我们之前做过的方案跟这个有相似之处，解密密钥在硬件中，只能写入不能读取，可以调用硬件在设备内部执行解密算法，这样，最外层的密钥在设备中，设备由甲方运维持有，也就丢掉了这个烫手的东西。

我纠结的就是我附言 1 里面提到的，这个方案侵入性太强，所有应用都需要置入操作硬件的 SDK ，修改服务的启动逻辑。要命的是，我们用到的开源中间件也得去改造，一旦改造，性质就变了，公司得负责到底。


我希望的方案和 @libook 相似
1. 要对信息进行区分，敏感信息也要分重要程度
2. 根据 [JR/T 0071—2012] ，安全分为物理层、网络层、主机层、应用层等，那么在特定外部安全环境下，一些不那么重要的敏感信息，可以存储明文。问题在于我不是权威，我的理解算个 P ，苦于没有可参照的成功案例，没有具体的权威规范。

@wolfie 我方服务需要自动启动，启动脚本里面不能写密码之类

@swulling 哎，这个我当时就想到了，A 担心甲方询问处理细节，到时候不好回答，也就是说他内心是不认可这种方案的