Delphi AES跨平台加解密实战：与Java/C#/JS无缝对接

1. 项目概述：为什么是Delphi与AES的跨平台组合？

在桌面应用、工业控制软件乃至遗留系统的维护与现代化改造中，Delphi的身影依然活跃。它凭借高效的RAD开发模式、强大的VCL/FMX组件库和稳定的原生编译能力，在特定领域内依然是不可替代的选择。然而，当这些应用需要与Web服务、移动App或其它现代系统进行安全数据交换时，一个核心挑战就浮现了：如何实现一套可靠、标准且能在不同系统间无缝对接的加解密方案？这正是“Delphi实现AES加解密算法与跨平台对接实战”要解决的核心问题。

AES（高级加密标准）作为全球通用的对称加密算法，无疑是解决这一问题的首选。它的安全性经过了时间的检验，并且几乎所有现代编程语言和平台都内置了对它的支持。但问题在于，Delphi自身提供的加密库（如TIdHMACSHA1相关的单元，或较老的DCPcrypt）在默认配置、填充模式、密钥处理方式上，常常与主流的Java、C#、Python、JavaScript等语言存在微妙的差异。这些差异在跨平台对接时，足以让加解密过程彻底失败，导致数据无法解析，而错误信息往往晦涩难懂，排查起来如同大海捞针。

因此，这个项目的目标远不止于在Delphi里调用一个加密函数那么简单。它的深层价值在于，构建一个“桥梁”：一套在Delphi中实现的、严格遵循通用标准（如PKCS#7填充、CBC模式）的AES加解密核心，并确保其输出能够被其他平台（如Java的Cipher类、C#的AesCryptoServiceProvider、Node.js的crypto模块）正确解密，反之亦然。这涉及到对算法细节的深刻理解、对字节和编码的精确控制，以及大量的边界情况测试。对于需要维护或开发涉及多系统交互的Delphi工程师来说，掌握这套实战技能，意味着能独立解决一类高频且棘手的技术集成问题，直接提升项目的交付质量和开发效率。

2. 核心需求解析与方案选型

2.1 跨平台对接的核心痛点

在动手写代码之前，我们必须先搞清楚，为什么Delphi的AES和其他平台的对不上。根据我处理过的数十个对接案例，问题几乎都集中在以下几个非算法本身的“外围”细节上：

1. 密钥与IV（初始化向量）的处理：AES算法本身要求密钥是固定长度的（如AES-128为16字节）。但业务系统给出的可能是一个密码字符串。如何从字符串生成密钥？是直接用UTF-8编码的字节，还是经过某种哈希（如SHA256）处理？IV是固定值、随机生成，还是从密钥派生？其他平台默认是怎么做的？不一致就会导致第一步就失败。
2. 加密模式与填充模式：AES有多种工作模式（如ECB、CBC、GCM）。ECB不安全，一般不用于敏感数据；GCM能同时提供加密和认证，但实现稍复杂。最常用的是CBC模式，它需要一个IV。填充模式则用于将数据补齐到块大小的整数倍，PKCS#7（有时也叫PKCS#5）是跨平台最通用的标准。Delphi的一些老旧库可能默认使用其他填充（如ZeroPadding），导致其他平台解密时提示“填充错误”。
3. 数据的编码与传输：加密后的输出是二进制字节数组。如何传输？通常需要将其转换为文本格式，Base64是最通用的选择。这里又涉及到字符编码（UTF-8）的问题。一个完整的流程是：明文文本 -> UTF-8字节 -> AES加密 -> 二进制密文 -> Base64编码 -> 文本密文。解密则反向进行。任何一步的编码不一致，都会得到乱码。
4. 库的实现差异：即使模式和填充声明一致，不同加密库在底层实现上可能有细微差别。例如，对空数据的处理、对IV长度的校验等。

2.2 方案选型：为什么选择mORMot或LockBox？

面对这些痛点，我们有几种选择：

• 使用Delphi自带的TNetEncoding.Base64和第三方加密库（如DCPcrypt2）：这是经典方案。DCPcrypt2功能强大，支持AES和多种模式。但它的API较为底层，需要开发者自己处理密钥派生、模式配置等所有细节，且不同版本间可能有行为差异，跨平台对接时需要做大量适配和测试工作。
• 调用操作系统原生API（如Windows的CryptoAPI）：性能好，但严重依赖Windows平台，与“跨平台”的初衷背道而驰。在Linux或macOS上部署FMX应用时此路不通。
• 使用成熟的第三方Delphi加密组件库：这是目前最推荐的做法。经过社区检验的库通常已经处理好了上述大部分兼容性问题。

在我的实战中，主要推荐两个库：

1. mORMot框架的加密单元：如果你已经在使用或考虑使用mORMot这个强大的ORM/服务框架，那么它的mormot.crypt.core.pas和mormot.crypt.openssl.pas单元提供了工业级的加密支持。它封装了OpenSSL，支持AES-GCM等现代模式，且默认行为与主流平台高度兼容。这是追求稳健和功能全面性的首选。
2. LockBox 3：这是一个轻量级、专注于加密的组件库。它的API设计清晰，对AES-CBC/PKCS7的支持非常直接，且社区中有大量关于与其他语言对接的示例。对于专注于实现AES加解密对接功能的项目来说，LockBox 3足够简单、够用。

本次实战，我将以LockBox 3为例进行讲解。原因在于它目标单一，依赖少，更容易让大家把注意力集中在AES跨平台对接的核心逻辑上，而不是被复杂的框架所干扰。当然，核心原理是相通的，理解了之后，迁移到mORMot或其他库也会非常容易。

注意：无论选择哪个库，请务必从官方仓库（如GitHub）获取最新稳定版本。旧版本可能存在已知的兼容性Bug。

3. 环境准备与LockBox 3集成

3.1 获取与安装LockBox 3

LockBox 3的源代码托管在GitHub上。我们不应直接下载二进制或使用来路不明的安装包，最好通过Git克隆或下载其Release版本的源码。

1. 获取源码：访问LockBox 3的GitHub仓库，下载最新的稳定版源码（通常是一个ZIP文件）。
2. 集成到项目：对于Delphi项目，我推荐使用“项目-选项-搜索路径”的方式来引用，而不是直接安装到IDE。这样做的好处是项目自包含，便于版本管理和团队协作。
   • 解压下载的ZIP文件，将其中的Source目录复制到你的项目根目录下，或者一个统一的第三方库目录中。
   • 打开你的Delphi项目，进入Project -> Options -> Building -> Delphi Compiler -> Search Path。
   • 添加LockBox 3源码所在的路径（例如：..\ThirdParty\LockBox3\Source）。
3. 验证：尝试在项目的uses部分添加uTPLb_CryptographicLibrary,uTPLb_Codec等单元，如果编译通过，说明集成成功。

3.2 创建跨平台加解密核心类

为了代码的复用和清晰，我们创建一个单独的单元文件，例如AESCrossPlatformHelper.pas，在其中封装所有加解密逻辑。

unit AESCrossPlatformHelper; interface uses System.SysUtils, System.Classes, uTPLb_CryptographicLibrary, uTPLb_Codec, uTPLb_Constants; type TAESHelper = class private FCryptoLib: TCryptographicLibrary; FCodec: TCodec; procedure ConfigureCodec(const AKey, AIV: TBytes; AEncryptMode: Boolean); public constructor Create; destructor Destroy; override; // 加密：明文文本 -> Base64密文文本 function EncryptAES_CBC_PKCS7(const PlainText, AKey, AIV: string): string; // 解密：Base64密文文本 -> 明文文本 function DecryptAES_CBC_PKCS7(const CipherTextBase64, AKey, AIV: string): string; // 更底层的字节数组操作 function EncryptBytes(const PlainBytes, AKey, AIV: TBytes): TBytes; function DecryptBytes(const CipherBytes, AKey, AIV: TBytes): TBytes; end; implementation { TAESHelper } constructor TAESHelper.Create; begin inherited; FCryptoLib := TCryptographicLibrary.Create(nil); FCodec := TCodec.Create(nil); FCodec.CryptoLibrary := FCryptoLib; // 指定使用AES算法，CBC模式，PKCS7填充 FCodec.StreamCipherId := BlockCipher_ProgId; FCodec.BlockCipherId := Format(AES_ProgId, [256]); // 使用AES-256，可根据需要改为128或192 FCodec.ChainModeId := CBC_ProgId; end; destructor TAESHelper.Destroy; begin FCodec.Free; FCryptoLib.Free; inherited; end; procedure TAESHelper.ConfigureCodec(const AKey, AIV: TBytes; AEncryptMode: Boolean); begin FCodec.Init; FCodec.Key := TMemoryStream.Create; FCodec.Key.WriteBuffer(AKey[0], Length(AKey)); FCodec.Key.Position := 0; // 设置初始化向量 FCodec.SetIV(TMemoryStream.Create); if Length(AIV) > 0 then begin FCodec.IV.WriteBuffer(AIV[0], Length(AIV)); FCodec.IV.Position := 0; end; // 设置加密或解密模式 if AEncryptMode then FCodec.Encrypt else FCodec.Decrypt; end; function TAESHelper.EncryptBytes(const PlainBytes, AKey, AIV: TBytes): TBytes; var InputStr, OutputStr: TMemoryStream; begin // 1. 配置Codec为加密模式 ConfigureCodec(AKey, AIV, True); InputStr := TMemoryStream.Create; OutputStr := TMemoryStream.Create; try // 2. 写入明文数据 if Length(PlainBytes) > 0 then InputStr.WriteBuffer(PlainBytes[0], Length(PlainBytes)); InputStr.Position := 0; // 3. 执行加密 FCodec.EncryptStream(InputStr, OutputStr); OutputStr.Position := 0; // 4. 读取加密后的字节 SetLength(Result, OutputStr.Size); OutputStr.ReadBuffer(Result[0], OutputStr.Size); finally InputStr.Free; OutputStr.Free; FCodec.Reset; // 重置Codec状态，为下一次操作做准备 end; end; function TAESHelper.DecryptBytes(const CipherBytes, AKey, AIV: TBytes): TBytes; var InputStr, OutputStr: TMemoryStream; begin // 1. 配置Codec为解密模式 ConfigureCodec(AKey, AIV, False); InputStr := TMemoryStream.Create; OutputStr := TMemoryStream.Create; try // 2. 写入密文数据 if Length(CipherBytes) > 0 then InputStr.WriteBuffer(CipherBytes[0], Length(CipherBytes)); InputStr.Position := 0; // 3. 执行解密 FCodec.DecryptStream(InputStr, OutputStr); OutputStr.Position := 0; // 4. 读取解密后的字节 SetLength(Result, OutputStr.Size); OutputStr.ReadBuffer(Result[0], OutputStr.Size); finally InputStr.Free; OutputStr.Free; FCodec.Reset; end; end; function TAESHelper.EncryptAES_CBC_PKCS7(const PlainText, AKey, AIV: string): string; var KeyBytes, IVBytes, PlainBytes, CipherBytes: TBytes; begin // 关键：统一使用UTF-8编码将字符串转换为字节数组 PlainBytes := TEncoding.UTF8.GetBytes(PlainText); KeyBytes := TEncoding.UTF8.GetBytes(AKey); IVBytes := TEncoding.UTF8.GetBytes(AIV); // 调用字节加密函数 CipherBytes := EncryptBytes(PlainBytes, KeyBytes, IVBytes); // 将加密后的字节数组转换为Base64字符串，便于传输 Result := TNetEncoding.Base64.EncodeBytesToString(CipherBytes); end; function TAESHelper.DecryptAES_CBC_PKCS7(const CipherTextBase64, AKey, AIV: string): string; var KeyBytes, IVBytes, CipherBytes, PlainBytes: TBytes; begin // 关键：将Base64字符串解码回字节数组 CipherBytes := TNetEncoding.Base64.DecodeStringToBytes(CipherTextBase64); KeyBytes := TEncoding.UTF8.GetBytes(AKey); IVBytes := TEncoding.UTF8.GetBytes(AIV); // 调用字节解密函数 PlainBytes := DecryptBytes(CipherBytes, KeyBytes, IVBytes); // 将解密后的字节数组用UTF-8编码转换回字符串 Result := TEncoding.UTF8.GetString(PlainBytes); end; end.

这个封装类提供了从字符串到字符串的便捷方法（EncryptAES_CBC_PKCS7/DecryptAES_CBC_PKCS7），内部清晰地处理了UTF-8编码和Base64转换。同时，也暴露了底层的字节数组操作接口（EncryptBytes/DecryptBytes），以备更灵活的使用场景。

4. 跨平台对接实战：与Java、C#、JavaScript互验

代码写好了，但能不能真正“跨平台”，必须用其他语言验证。这是最关键的步骤。我们假设一个通用的对接场景：密钥为字符串“MySuperSecretKey32BytesLong!123”，IV为字符串“InitializationVe”，明文为“Hello, Cross-Platform AES!”。

4.1 Delphi端加密输出

使用我们刚写的辅助类：

var AESHelper: TAESHelper; EncryptedText: string; begin AESHelper := TAESHelper.Create; try EncryptedText := AESHelper.EncryptAES_CBC_PKCS7( 'Hello, Cross-Platform AES!', 'MySuperSecretKey32BytesLong!123', 'InitializationVe' ); Memo1.Lines.Add('Delphi Encrypted (Base64): ' + EncryptedText); finally AESHelper.Free; end; end;

运行后，我们可能会得到一个Base64字符串，例如：“S/L7rHvLm8eXqKzT8Z1F2QKp1oW7nY+JcVfE5tGjBkY=”（此为示例，实际结果会因IV随机性等因素不同）。

4.2 Java端解密验证

在Java（以Spring Boot环境为例）中，我们使用标准的javax.crypto.Cipher类进行解密。

import javax.crypto.Cipher; import javax.crypto.spec.IvParameterSpec; import javax.crypto.spec.SecretKeySpec; import java.util.Base64; public class AesCrossPlatformTest { public static void main(String[] args) throws Exception { String encryptedTextBase64 = "S/L7rHvLm8eXqKzT8Z1F2QKp1oW7nY+JcVfE5tGjBkY="; // 替换为Delphi输出的实际值 String key = "MySuperSecretKey32BytesLong!123"; String iv = "InitializationVe"; // 1. Base64解码 byte[] cipherBytes = Base64.getDecoder().decode(encryptedTextBase64); byte[] keyBytes = key.getBytes("UTF-8"); byte[] ivBytes = iv.getBytes("UTF-8"); // 2. 创建密钥和IV规范 SecretKeySpec secretKeySpec = new SecretKeySpec(keyBytes, "AES"); IvParameterSpec ivParameterSpec = new IvParameterSpec(ivBytes); // 3. 初始化Cipher为解密模式，使用AES/CBC/PKCS5Padding (PKCS5Padding在AES块大小下等同于PKCS7) Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding"); cipher.init(Cipher.DECRYPT_MODE, secretKeySpec, ivParameterSpec); // 4. 执行解密 byte[] decryptedBytes = cipher.doFinal(cipherBytes); String decryptedText = new String(decryptedBytes, "UTF-8"); System.out.println("Java Decrypted: " + decryptedText); // 应输出：Hello, Cross-Platform AES! } }

4.3 C# (.NET) 端解密验证

在C#中，我们使用System.Security.Cryptography.Aes类。

using System; using System.Text; using System.Security.Cryptography; class Program { static void Main() { string encryptedTextBase64 = "S/L7rHvLm8eXqKzT8Z1F2QKp1oW7nY+JcVfE5tGjBkY="; string key = "MySuperSecretKey32BytesLong!123"; string iv = "InitializationVe"; // 1. Base64解码 byte[] cipherBytes = Convert.FromBase64String(encryptedTextBase64); byte[] keyBytes = Encoding.UTF8.GetBytes(key); byte[] ivBytes = Encoding.UTF8.GetBytes(iv); // 2. 使用AES创建解密器 using (Aes aesAlg = Aes.Create()) { aesAlg.Key = keyBytes; aesAlg.IV = ivBytes; aesAlg.Mode = CipherMode.CBC; aesAlg.Padding = PaddingMode.PKCS7; // 关键：使用PKCS7 // 3. 创建解密流 ICryptoTransform decryptor = aesAlg.CreateDecryptor(aesAlg.Key, aesAlg.IV); // 4. 执行解密 using (MemoryStream msDecrypt = new MemoryStream(cipherBytes)) using (CryptoStream csDecrypt = new CryptoStream(msDecrypt, decryptor, CryptoStreamMode.Read)) using (StreamReader srDecrypt = new StreamReader(csDecrypt, Encoding.UTF8)) { string decryptedText = srDecrypt.ReadToEnd(); Console.WriteLine("C# Decrypted: " + decryptedText); } } } }

4.4 JavaScript (Node.js) 端解密验证

在Node.js环境中，使用内置的crypto模块。

const crypto = require('crypto'); const encryptedTextBase64 = 'S/L7rHvLm8eXqKzT8Z1F2QKp1oW7nY+JcVfE5tGjBkY='; const key = 'MySuperSecretKey32BytesLong!123'; const iv = 'InitializationVe'; // 1. 将字符串密钥和IV转换为Buffer，使用UTF-8编码 const keyBuffer = Buffer.from(key, 'utf-8'); const ivBuffer = Buffer.from(iv, 'utf-8'); const cipherBuffer = Buffer.from(encryptedTextBase64, 'base64'); // 2. 创建解密器，指定算法为'aes-256-cbc'，自动使用PKCS7填充 const decipher = crypto.createDecipheriv('aes-256-cbc', keyBuffer, ivBuffer); // 3. 执行解密并指定输出编码 let decrypted = decipher.update(cipherBuffer, null, 'utf8'); decrypted += decipher.final('utf8'); console.log('Node.js Decrypted:', decrypted);

如果以上三个平台的解密代码都能成功输出“Hello, Cross-Platform AES!”，那么恭喜你，Delphi端的AES实现成功实现了跨平台兼容。反之，如果任何一方失败，就需要根据错误信息进入下一章的排查环节。

实操心得：在编写这些测试用例时，务必保持密钥、IV、明文完全一致。建议先将Delphi加密后的Base64输出写死到其他语言的测试代码中，排除因动态生成导致的变量不一致问题。这是一个非常有效的隔离调试手段。

5. 深度排查：当对接失败时怎么办？

即使按照上述步骤操作，在实际对接中仍可能遇到问题。下面是一个根据我踩坑经验总结的排查清单，基本能覆盖90%以上的对接失败场景。

5.1 常见错误现象与原因分析

5.2 高级调试技巧：十六进制转储比对

当逻辑检查无法定位问题时，最强大的工具是十六进制比对。不要只看Base64字符串，要深入到字节层面。

在Delphi端，加密后，将密钥字节、IV字节、明文字节、密文字节都转为十六进制字符串打印出来。

function BytesToHex(const Bytes: TBytes): string; var I: Integer; begin Result := ''; for I := 0 to Length(Bytes) - 1 do Result := Result + IntToHex(Bytes[I], 2); end; // 在加密函数内添加日志 PlainBytes := TEncoding.UTF8.GetBytes(PlainText); KeyBytes := TEncoding.UTF8.GetBytes(AKey); IVBytes := TEncoding.UTF8.GetBytes(AIV); Memo1.Lines.Add('Key Hex: ' + BytesToHex(KeyBytes)); Memo1.Lines.Add('IV Hex: ' + BytesToHex(IVBytes)); Memo1.Lines.Add('PlainText Hex: ' + BytesToHex(PlainBytes)); CipherBytes := EncryptBytes(PlainBytes, KeyBytes, IVBytes); Memo1.Lines.Add('CipherText Hex: ' + BytesToHex(CipherBytes));

同样地，在Java、C#或JavaScript端，在解密前，也将收到的Base64密文解码，然后打印其十六进制，以及本地用于解密的密钥和IV的十六进制。对比双方日志中的这些十六进制字符串，任何差异都会一目了然。我曾用这个方法解决过一个困扰团队两天的问题：发现是运维在配置Nginx反向代理时，无意中开启了对响应体的gzip压缩，导致密文二进制被破坏，Base64解码自然失败。

5.3 关于密钥派生与IV管理的建议

在更严肃的生产环境中，直接使用字符串的UTF-8字节作为密钥并不安全，特别是当密钥来源于用户输入的密码时。标准的做法是使用PBKDF2（Password-Based Key Derivation Function 2）算法，从密码和盐值（Salt）派生出一个固定长度的、密码学强度高的密钥。

LockBox 3也支持PBKDF2。你可以使用uTPLb_PBKDF2单元来生成密钥，确保与其他平台（如Java的PBEKeySpec）使用相同的迭代次数、盐值和哈希算法（如SHA256），从而生成完全一致的密钥字节。对于IV，最佳实践是每次加密都随机生成一个，然后将这个IV和密文一起传输（通常将IV放在密文前面）。解密方先提取IV，再用它来解密。这样可以大大提高安全性。

6. 性能考量与FMX跨平台部署

6.1 Delphi AES实现的性能

对于大多数应用层的数据加密（如传输JSON、加密配置文件），LockBox 3或mORMot的纯Pascal实现性能完全足够。加密解密一个几KB到几百KB的数据包，耗时在毫秒级，用户无感知。

如果遇到需要加密/解密大量数据（如实时视频流、大型文件）的场景，可以考虑以下优化：

1. 使用流式处理：我们示例中的EncryptStream和DecryptStream本身就是流式操作，适合处理大文件，无需将整个文件加载到内存。
2. 启用汇编优化：一些加密库（如DCPcrypt）的特定版本针对Intel处理器提供了汇编优化的代码路径，可以显著提升速度。LockBox 3的部分核心算法也可能有优化。
3. 平台原生库：在确定目标平台后，可以考虑使用平台原生的API。例如在Windows上，通过JNI调用Java的Cipher，或通过P/Invoke调用C#的Aes类（在Delphi中与.NET交互）。但这会牺牲代码的统一性和可移植性，仅在性能瓶颈确凿且平台固定的情况下考虑。

6.2 在FireMonkey跨平台项目中的注意事项

我们的TAESHelper类基于LockBox 3，而LockBox 3是纯Pascal代码，不依赖特定平台的API。因此，它可以完美地编译到Windows、macOS、iOS、Android等所有FireMonkey支持的目标平台，这是它最大的优势之一。

在部署时，需要注意：

• 库文件包含：确保LockBox 3的源码路径已正确添加到所有目标平台的搜索路径中。
• Android权限：如果你的Android应用需要进行网络传输加密数据，通常不需要特殊权限。但如果你使用更高级的特性（如从系统密钥库获取密钥），可能需要声明相应权限。
• iOS的App Transport Security：如果加密后的数据通过HTTPS传输，iOS的ATS默认是安全的。如果是自有协议，则无需额外配置。
• 调试：在移动端（尤其是Android）调试加密逻辑时，将关键的十六进制日志输出到控制台或文件，比在桌面端更麻烦。建议在开发阶段，可以增加一个“调试模式”开关，将日志通过网络发送到开发机，或写入设备中可访问的临时文件。

7. 从示例到生产：安全加固与实践建议

将示例代码转化为生产代码，还需要在安全性和鲁棒性上做更多工作。

1. 错误处理：示例中省略了错误处理以保持清晰。在生产代码中，必须用try...except包裹加解密操作，捕获诸如ECryptographicError之类的异常，并转换为友好的错误信息或日志，避免程序崩溃。
2. 密钥管理：绝对不要将密钥硬编码在源代码中。密钥应该来自安全的配置源，如经过加密的配置文件、环境变量、或硬件安全模块。对于移动应用，可以考虑使用平台提供的安全存储（如Android的Keystore、iOS的Keychain）。
3. 使用Authenticated Encryption：CBC模式本身只能保证机密性，不能保证完整性。攻击者可能篡改IV或密文。对于高安全要求场景，应考虑使用AES-GCM模式，它同时提供加密和认证。LockBox 3和mORMot都支持GCM模式，但对接时需确保其他平台也支持，且处理认证标签的方式一致。
4. 代码混淆与保护：虽然Delphi是原生编译，但字符串常量（如密钥）在二进制文件中仍可能被找到。可以考虑将密钥拆分成多个部分，在运行时组合，或使用代码混淆工具增加逆向工程难度。
5. 依赖库版本锁定：确保团队所有成员以及构建服务器都使用相同版本的LockBox 3源码。加密库行为的细微变化可能导致线上事故。

我个人在多个跨平台项目中使用这套方案后，最大的体会是：标准化和一致性是跨平台加解密成功的基石。一旦确定了编码（UTF-8）、模式（CBC）、填充（PKCS#7）、密钥派生方法（如果需要）和IV处理方式，就要在所有参与系统中严格遵循。建立一个包含Delphi、Java、C#、JavaScript等语言的统一测试用例集，每次更新加密逻辑后都跑一遍，能极大降低集成风险。这套看似简单的AES加解密，实则是连接新旧系统、不同技术栈的可靠桥梁，把它搭稳了，数据安全流动的通道也就畅通了。