修复 cipher-aes 存储配置文件时，首次创建文件时仅将加密内容存储在数据库中。再次修改配置文件会导致数据库中的加密内容变成明文。
修复cipher-aes存储配置文件时，只有首先创建文件才会在数据库中存储加密内容，再次修改配置文件，数据库中的加密内容会变成明文的缺陷问题。
https://github.com/alibaba/nacos/blob/84b3afc fcaeefbc66e1d20d2e1911d96efdeec0f/config/src/main/java/com/alibaba/nacos/config/server/controller/ConfigController.java#L147-L173 为什么需要通过加密和发布配置时是否使用encryptedDataKey？当以 cipher-aes 格式发布配置时，理想情况下每次都应生成此 cryptoDataKey 并用于加密内容。
我发现了当前实施中的一个缺陷。在初始配置发布期间，由于未提供encryptedDataKey，该EncryptionHandler.encryptHandler(dataId, content)函数对数据进行了加密。但在后续的修改操作中，前端提供了加密的DataKey，导致修改的内容没有被加密。
理论上，内部EncryptionHandler.encryptHandler(dataId, content)有一个checkCipher根据dataId进行验证的方法，同时考虑到配置不加密发布的场景。因此，我认为第165行的条件检查可能有些多余
此外，这里似乎不需要encryptedDataKey 参数。如果发布配置时不加密，则encryptedDataKey应为空。加密发布配置的情况下，生成新的encryptedDataKey
是否还有其他需要此条件的上下文或场景？我还没有找到任何额外的信息。@KomachiSion
加密和发布配置时需要传递encryptedDataKey，否则nacos插件不知道如何加密内容。
加密内容是通过插件生成的secretKey和content生成的，跟encryptedDataKey看起来是无关的
我认为可以去掉这个判断，每次加密创建&发布配置都会根据secretKey和content生成加密内容
插件有一种情况是在客户端加密后传入服务端。 这种情况传输过程中也是密文。
控制台是因为不支持插件扩展， 所以只能在服务端进行加密，你看起来才是都是在服务端生成的。
那就是有两种情况：
可不可以在ConfigController#searchConfig方法的响应对象ConfigInfo里面加一个字段，用于区分是否是控制台进行的配置发布，这样在控制台发布配置的时候，就能通过这个字段去判断是否需要对content进行加密了，现在的问题就是控制台发布配置的时候encryptedDataKey不为空，导致服务端以为不需要对content进行加密了，是否能加一个字段区分这种控制台发布配置的情况
或者说大佬你还有什么好的方法吗？
主要还是要梳理一下加密插件的工作流，这块之前是 @li-xiao-shuang 做的， 等后面有空了我再和 @shiyiyue1102 等配置中心的大佬一起梳理下吧。