为了安全是这样啦，我还见过编译时 SQL 检查呢，SQL 写错代码都不能编译

一起看过有一个 Go 的爬虫,或许对你有用 https://github.com/shiyanhui/dht

抓个小虫

`这是 Spring Security 中非常关键的一个基类, 等同于 Spring 框架原生态的给了你一个实现模板, 以常见的 username/password 的形式, 实现了基本的鉴权入口`


应该叫认证哈，鉴权是另一个的概念，你这篇文章都是在讲认证处理。

设计模式采用发布-订阅，底层技术可选的很多，redis pubusb ，postgres channels ，或者直接上专业 MQ

仓库倒是可以帮你 star ，可是博客属实没什么内容呀

你随便找的动态库，如果版本不对也可能会崩溃的。不是动态名字一样能启动这么简单。

frp 把 ssh 打通，或者楼上的方案用 直接用 zerotier ，tailscale 把网络打通。后者统一管理方便，但数量上去了可能需要付费。
另外因为网络打通了，就有了远程管理的可能性，所以实际上解决网络问题。

Intel 的 U 搞虚拟化舒服点,可以 GVT,把核显拆成几个给虚拟机用，如果是简单桌面操作系统的话还是挺实用。

分享一点经验：

## C 风格字符串

需要注意 C 风格字符串是靠 null-byte(0x0)标记字符串长度

## 结构体传参

要注意是 ByReference 还是 ByValue ，核对 C 端的函数原型

## 结构体内存布局

要注意对齐方式,仔细核对 C 端的结构体声明

## 结构体 memory dump

开启 `-Djna.dump_memory=true`

> Normally when you invoke toString on a Structure, it will print each defined field with its calculated memory offset. If when launching the VM, you pass it "-Djna.dump_memory=true", toString will also dump the contents of the corresponding native memory. This is useful to determine if you've added or omitted a field, or chosen an incorrect size. Viewing the memory as bytes usually makes it clear where field boundaries should be, assuming the memory has been initialized by native code.

## 日志

对 C 端的函数调用做一下封装,调用前后记录日志，先把崩溃的位置找到

没有找到稳定的复现方法还不好说，大概率是 JAVA 和 C 库共享内存的问题，小概率是 C 库自己的问题。

边学边干，哪里不会点哪里 — chatgpt

我看这没什么问题呀，你意思是 app name 和 ctx path 不同就有不一样的行为？

恭喜，这下真榜一大哥了

公开信用评级，让用户自己选择

想引流就搞点像样的东西

看了一下大家的回复，符合我对这个标题的预期。

用户名 cppc

感谢