由于系统之前使用的Nacos2.0.4有反序列化漏洞，故需要将Nacos升级到2.2.3版本。
该Nacos在本地运行没有问题，但是在Windows服务器运行就会报错：

rocksdb java.lang.UnsatisfiedLinkError: C:\Users\Administrator\AppData\Local\Temp\2\librocksdbjni5975940319059115965.dll: Can't find dependent libraries

表面上看是找不到dll文件，于是去百度，发现各种解决办法均无效。

刨根究底，发现这个问题是由于Nacos引用了rocksdb导致的，于是从rocksdb着手解决。

猜想过是因为jar包没有Temp目录的权限，从而导入文件失败导致，直接手动复制文件进目录，已然报错。
后来发现有网友说手动导入rocksdb依赖：

<dependency><groupId>org.rocksdb</groupId><artifactId>rocksdbjni</artifactId><version>版本号改成了跟Nacos依赖相同的版本</version><classifier>win64</classifier>
</dependency>

导入后发现这个依赖只是Nacos原有依赖排除掉除win64外的其他版本，并没有什么帮助。

陷入思考……

突然想到，之前旧版本(5.18.4)可以正常使用，这次Nacos2.2.3依赖的7.7.3却无法正常使用，怀疑是导入的依赖与系统(CPU?)不兼容。

于是将导入的rocksdb依赖改为：

<dependency><groupId>org.rocksdb</groupId><artifactId>rocksdbjni</artifactId><version>5.18.4</version><classifier>win64</classifier>
</dependency>

也就是改成了Nacos2.0.4依赖的rocksdb。
但是启动报了另外一个错，具体就不贴了，意思就是有一个方法不存在，猜想是7.7.3对5.18.4增加了新的方法，而且Nacos2.2.3使用了。

于是直接上mvn仓库找到最新版rocksdb，将依赖改为：

<dependency><groupId>org.rocksdb</groupId><artifactId>rocksdbjni</artifactId><version>9.2.1</version><classifier>win64</classifier>
</dependency>

然后本地测试的时候发现aliyun没有这么高等级的依赖，只能降到7.10.2才能依赖进来。

但是7.10.2和7.7.3存在着相同的问题。

于是打算从5.18.4 ~ 7.7.3之间来寻找一个能用的依赖。

直接试了6.29.5，也就是升级大版本7之前的最高版本。

然后启动成功！

总结：
Nacos项目新增依赖如下(放到所有依赖最上面)：

<dependency><groupId>org.rocksdb</groupId><artifactId>rocksdbjni</artifactId><version>6.29.5</version><classifier>win64</classifier>
</dependency>