免费数据加密API选型指南：六款主流方案深度解析

做后端开发这几年，数据加密一直是个绕不开的话题。尤其是当业务里出现用户手机号、身份证号、银行卡号、订单金额这类敏感字段时，光靠数据库权限控制已经不够用了——一旦发生拖库、备份泄露或者日志外泄，明文数据就是直接裸奔。所以我现在做项目，凡是涉及敏感信息存储和传输的，第一反应就是先接入一套数据加密API，把“加密”变成一种默认能力，而不是事后补救。

这次分享的六款免费数据加密API，都是我在不同项目里实际用过、测过，甚至踩过坑才留下来的候选方案。它们覆盖了对称加密、密钥托管、哈希校验、文件加密、传输通道加密、算法聚合封装这六种典型需求，基本可以满足从个人小项目到准生产环境的加密诉求。我会从选型思路讲起，再到每个API的核心特性、适合场景，最后给出一套可以直接上手的实战流程，包括调用代码、参数选择、权限配置和常见报错排查。无论你是第一次接触加密API的新手，还是在为现有系统选型的老手，这篇文章应该都能让你少走一些弯路。

1. 为什么需要“加密 API”：不只是加个密那么简单

很多人一开始的想法是：我自己写个AES函数，把数据加密存进数据库不就行了吗？确实，能加密比不加密强，但这个思路在实际落地中会遇到几个很现实的问题。

第一，加密算法选型容易出错。同样是AES，有ECB、CBC、GCM多种模式，密钥长度有128、192、256，填充方式有PKCS5Padding、PKCS7Padding，初始化向量IV的生成方式和长度也有讲究。这些参数组合起来，任何一个环节错了，要么加密强度不够，要么不同环境之间无法互相解密。更麻烦的是，像ECB模式这种“看起来能用”的模式，其实存在明显的模式泄露问题——相同明文块会得到相同密文块，这在真实业务里很容易被攻击者利用。

第二，密钥管理是个大坑。如果密钥写死在代码里、放在配置文件里、或者塞进数据库某个字段，那这把锁基本等于没锁。一旦源码泄露或者运维人员失误暴露了配置文件，所有历史密文都可以被轻易解开。生产环境里，密钥应该单独存储、定期轮换、按权限分发，还要有审计日志，这些能力自己从零搭建非常耗费精力。

第三，加解密性能需要调优。加密不是一次性的操作，一个高并发的订单系统，每秒可能有几百甚至上千次加密调用。如果在应用服务器本地做大文件加密，还会占用大量的CPU和内存资源。把加密操作做成独立API服务，可以通过水平扩容来应对峰值流量，也能把性能问题隔离在加密服务内部，不影响业务主链路。

所以，加密API的核心价值，不是“替你写一个加密函数”，而是把算法选型、密钥托管、性能优化、权限审计、兼容性处理这些脏活累活全部封装好，你只需要用最简单的方式调用，就能获得一个相对可靠的安全底座。

1.1 什么时候真正需要“免费的加密API”

我把使用场景归纳为四类，大家可以对号入座。

• 个人开发者做练手项目或毕业设计，预算有限，需要快速给登录注册模块加上密码加密存储和传输保护能力。
• 小团队在做内部管理系统、CRM、工单系统，需要加密接口对接微信、支付、物流等平台敏感数据，但暂时没有专职安全工程师。
• 传统行业做数字化转型试点，业务数据要上云，但合规审计要求数据在存储时必须处于密文状态。
• 二次开发某开源系统，希望在尽量少改业务代码的前提下，通过HTTP API把原有明文存储的敏感字段替换为加密后的密文字段。

以上这些场景，免费加密API完全够用。但要注意一个前提：所谓“免费”，通常意味着有调用次数限制、单次请求数据大小限制、功能子集限制，或者仅限非商业用途。在把免费方案引入正式商用项目前，必须仔细阅读服务条款，尤其是权责边界、数据留存策略和服务可用性承诺。别因为“免费”就忽略这些细节，加密服务不同于普通工具类API，它经手的是你最敏感的数据。

1.2 免费方案的安全边界

免费真的能保证安全吗？这个问题需要理性看待。

首先，加密算法本身是公开的，AES、RSA、ChaCha20这些算法的安全性不取决于算法保密，而取决于密钥安全。也就是说，无论你用免费API还是商业方案，只要密钥管理得当、算法参数正确，加密强度本身是可信的。

其次，免费API的安全短板通常不在算法层面，而在配套能力层面，比如：密钥的自动轮换策略是否可配置、是否有完善的密钥访问审计、是否提供合规的删除和销毁机制、团队权限管理是否细化到用户级别。这些能力很多免费额度下是不开放的。

我个人的实践原则是：免费API可以做技术验证、内部工具、低敏业务，也可以作为学习加密体系的最佳入口。但凡是涉真金白银、涉大规模用户隐私的严肃生产系统，我一定会为加密服务预留商业预算，至少在密钥托管和审计能力上付费。这个不是对免费方案不信任，而是对安全体系的投入本来就应该和业务价值成正比。

2. 六个免费数据加密API逐一解析

这部分是全文的核心，我把六款API按使用频率和典型场景做了排序。需要提前说明的是，为了讨论方便，我使用了代称而非真实品牌名，但它们的功能特性和选型思路是完全复刻自真实方案的。如果你在选型时发现了实际服务，可以按照我这里的判断维度去做对比。

2.1 CipherCloud API：通用对称加密的首选

CipherCloud API是我在实际项目中使用频率最高的一个。它的特点非常鲜明：只做一件事，就是数据加解密，但把这个功能做到极度顺手。

它默认支持AES-256-GCM加密模式。选GCM而不是CBC，是一个非常重要的设计决策。GCM是伽罗瓦计数器模式，它同时提供机密性和完整性校验。简单说，CBC模式只能保证数据不被偷看，但无法防止密文在传输过程中被恶意篡改；而GCM模式在加密的同时会生成一个认证标签，解密时先校验标签，一旦密文被改动哪怕一个字节，解密就会直接失败。这就相当于给加密数据加了一层防伪封条。

CipherCloud API另一个实用特性是支持“自带密钥”和“平台托管密钥”两种模式。自带密钥模式下，由你在本地生成主密钥，只把密文发送到API服务，平台本身不接触你的原始密钥，适合对密钥主权要求极高的场景；平台托管密钥模式则适合团队协作，密钥由服务统一管理，每次加密传一个标识即可。

它的接口设计也比较符合直觉，核心就三个接口：加密、解密、生成数据密钥。加密接口接收明文和密钥标识，返回密文和认证标签；解密接口反向操作。每个密钥还可以配置自定义元数据，比如备注用途、设置有效期，方便后期审计。

适合场景：数据库敏感字段加密、配置中心密码加密、第三方接口返回的敏感JSON字段脱敏后落库。后端服务调用它，平均单次加密耗时在10毫秒以内，并发表现稳定。

2.2 KeyVault API：专注密钥全生命周期管理

有句老话叫“密码学最薄弱的环节根本不是算法，而是密钥管理”。很多系统明明用了AES-256，最后却因为密钥存在服务器某个txt文件里而功亏一篑。KeyVault API就是为了解决这个问题而存在的。

它是专门的密钥管理服务，核心能力包括：密钥的生成、存储、轮换、备份、恢复、销毁，以及细粒度的访问审计。密钥本身以硬件安全模块或等价的安全容器存储，外部无法直接导出明文密钥。调用方只能通过API使用密钥进行加解密或签名验签，可以拿到密文，但拿不到密钥本身，这一点非常关键。

KeyVault API支持按环境区分密钥版本，比如开发环境、测试环境、生产环境可以各自持有独立密钥，互不交叉。密钥轮换时可以配置旧密钥继续生效一段时间，新密钥加密新数据，解密旧数据时自动匹配历史版本，从而实现无缝轮换，不用在业务代码里做兼容判断。

我特别推荐它的权限审计能力。每一次密钥的读取、加密、解密操作都会记录调用者身份、时间、调用来源IP和操作结果。当安全事件发生时，这不是可有可无的锦上添花，而是追根溯源的基础。

适合场景：作为所有其他加密API的底层支撑，统一管理业务密钥；满足合规审计要求的企业内部系统；多人协作且需要区分密钥操作权限的开发团队。

2.3 HashGuard API：数据完整性校验小能手

严格来说，HashGuard API做的不只是“哈希计算”，它更擅长的是数据完整性校验和防篡改检测。

它提供SHA-256、SHA-3、HMAC-SHA256三类算法接口。SHA-256适合计算文件或消息的指纹，校验数据在传输和存储过程中是否被改动；HMAC-SHA256适合做带密钥的完整性校验，相比纯哈希，它能防止攻击者在不知道密钥的情况下伪造数据及对应的哈希值。

HashGuard API有个比较省心的功能是“哈希策略模板管理”。你可以提前定义多个策略，比如“登录密码哈希策略”指定使用PBKDF2算法，迭代次数10000次，输出长度256位；“文件完整性策略”指定使用SHA-256；“Webhook验签策略”指定使用HMAC-SHA256，密钥来自KeyVault某版本。之后每次调用只需要传策略名称，不用每次拼接参数，既降低出错率，也让配置更集中。

在使用登录密码场景时要注意一点：不要用普通のSHA-256直接存密码，正确做法是使用PBKDF2、bcrypt或argon2这类专为密码设计的慢速哈希算法。HashGuard API也封装了PBKDF2能力，这是它的一个隐藏卖点。

适合场景：用户密码哈希存储、接口签名校验、文件完整性与版本一致性校验、防止加密数据被恶意篡改后入库。

2.4 DataSeal API：流式大文件加密的工程化方案

前几款API适合加密短字符串和结构化字段，但碰到几百MB甚至几GB的文件时，普通接口就不太够用了。DataSeal API是我用过的第一款真正把“文件加密”做成工程化方案的免费接口。

它支持流式加密上传，调用方把文件以块为单位分片上传，服务端实时加密后写入目标存储，全程不需要在业务服务器上完整加载文件到内存。这对于云服务器只有1GB内存的小配置来说，优势非常明显。大文件加密如果一次性读入内存，很容易触发内存溢出，流式处理让内存占用恒定在极低水平。

DataSeal API采用信封加密机制：在服务端生成一次性的数据加密密钥，用它加密文件内容，再用主密钥加密这个数据密钥。解密时先用权限换取主密钥对应的解密能力，解开数据密钥，再解文件内容。这样做的好处是：即使数据加密密钥泄露，攻击者也无法直接解开文件，因为没有主密钥对应的解密权限；同时每次加密文件都使用全新密钥，有效避免同密钥反复加密大量数据带来的风险。

它还提供文件指纹验证功能，加密的同时计算文件哈希，解密后返还哈希比对值，一次性解决“加密”“防篡改”“完整性验证”三个问题。

适合场景：数据库备份文件加密、用户证件照片或合同文件的加密存储、日志归档加密、对象存储的加密前处理。

2.5 SecureTransmit API：上云传输链路的应用层加密

客户端到服务器之间的HTTPS加密解决的是“中间人窃听”问题，但只要数据在内部网络各服务之间流转，经过网关、负载均衡、消息队列这些节点，很多环节都以明文方式短暂暴露。SecureTransmit API专门用来在应用层再包一层加密防护。

它的思路是端到端加密通道。调用方使用它提供的SDK，在发送方将消息加密，通过任意传输通道传给接收方，接收方再调用API解密。密钥成对使用，发送方持有加密公钥，接收方持有解密私钥，私钥不离开接收方所在环境，中间任何转发节点即使截获数据，拿到的也只是密文。

需要注意，SecureTransmit API不替代HTTPS，它是在HTTPS之上再增加一层应用层加密。它的价值在于解决内部网络信任边界的模糊问题，尤其是现在很多系统使用微服务架构，服务间调用链很长，你根本不知道流量会在哪一层被记录。业务层面加一道密，即使网络层出了问题，数据也仍然是安全的。

适合场景：跨系统接口对接时的敏感请求字段加密、微服务间调用敏感参数传递、消息队列中的业务消息加密、外部合作伙伴数据交换时的端到端加密交付。

2.6 OpenCrypto API：多算法聚合的学习与实践入口

最后这款OpenCrypto API，可以理解为一个“加密算法全家桶”。它聚合了AES、ChaCha20、SM4、RSA、ECDSA、Ed25519等多种常用算法，同时支持哈希、签名、密钥交换等能力，接口风格统一，适合做加密技术学习和多算法业务支撑。

相比前几款API的单点专注，OpenCrypto API更像一个开放的加密实验室。它的免费额度非常慷慨，单日调用次数可达上万次，而且支持自定义算法参数，比如AES的填充模式、RSA的密钥长度，自由度很高。

如果你是第一次接触数据加密API，我非常推荐从OpenCrypto API开始练手。它的文档完整，有大量代码示例，支持一键生成API调试页面，可以把每个算法的输入输出变化直观地看到。搞懂一个接口是怎么把“明文+密钥+参数”变成“密文+认证标签”的，再去理解其它专业API的设计思路，难度会降一个台阶。

还有一点，OpenCrypto API支持国密算法SM4和SM3，对国密合规有特殊要求的业务而言，这是一个很方便的技术验证入口。

适合场景：加密技术教学实践、多算法技术选型对比、小流量业务的多场景加密需求、对国密算法有预研需求的项目。

3. 从入门到实战：完整上手指南

选型只是第一步，真正把加密API接入业务系统，需要自己动手走一遍流程。下面我结合CipherCloud API和KeyVault API，给你一条从零到一的实操路径。这套路径是我在多个项目中沉淀下来的，直接照着做基本能跑通。

3.1 入门第一步：账号开通与密钥准备

每款加密API的第一步都大同小异：注册账号、创建应用、获取应用凭证。这个凭证通常包含一组应用密钥（AppKey/AppSecret），用于标识调用者身份。

这里有一个关键的安全教训：不要在代码里硬编码Secret。我在早期项目里吃过亏，把Secret直接写在配置类里，结果项目代码被上传到公开仓库，几分钟后就有扫描工具尝试通过这个Secret调用API。正确做法是把Secret放入环境变量或交由密钥管理服务统一托管，运行时读取。即使代码泄露，Secret本身不会跟着泄露。

# 本地开发环境示例（不要提交到仓库） export CIPHERCLOUD_APP_KEY="your-app-key-here" export CIPHERCLOUD_APP_SECRET="your-app-secret-here"

然后建议创建至少两个环境隔离的应用：一个“开发测试应用”，一个“生产应用”。两者使用完全独立的密钥和配额，避免开发调试时的调用污染生产环境的配额统计。顺便还能在API调用日志里分清来源。

3.2 实战示例：用户手机号加密存储

接下来我以最常见的场景——用户手机号加密存储——来演示完整链路。

首先，在KeyVault API中创建一个数据密钥，指定算法为AES-256-GCM，用途标记为“用户手机号加密”。

然后调用CipherCloud API执行加密：

import os import requests import json API_BASE = "https://ciphercloud-api.example.com/v1" APP_KEY = os.environ.get("CIPHERCLOUD_APP_KEY") APP_SECRET = os.environ.get("CIPHERCLOUD_APP_SECRET") def encrypt_field(plaintext: str, key_id: str) -> dict: """ 加密单个敏感字段。 入参：明文、密钥ID 返回：密文、认证标签、密钥版本 """ headers = { "X-APP-Key": APP_KEY, "X-APP-Secret": APP_SECRET, "Content-Type": "application/json" } payload = { "action": "encrypt", "algorithm": "AES-256-GCM", "key_id": key_id, "plaintext": plaintext } resp = requests.post(f"{API_BASE}/crypto", json=payload, headers=headers, timeout=10) if resp.status_code == 200: data = resp.json() return { "ciphertext": data["ciphertext"], "tag": data["tag"], "key_version": data["key_version"] } else: # 把错误信息原样抛出，方便排查 raise RuntimeError(f"encrypt failed: {resp.status_code} {resp.text}") # 使用示例 result = encrypt_field("13800138000", "key-user-mobile-prod") print(json.dumps(result, ensure_ascii=False))

返回的ciphertext和tag，连同key_version一起存入数据库对应字段。存储tag不可省略，因为GCM解密时要用它做完整性校验。

解密时，传入密文、tag和密钥ID：

def decrypt_field(ciphertext: str, tag: str, key_id: str) -> str: """ 解密字段。 参数需包含加密时返回的tag，完整性校验失败会直接报错。 """ headers = { "X-APP-Key": APP_KEY, "X-APP-Secret": APP_SECRET, "Content-Type": "application/json" } payload = { "action": "decrypt", "algorithm": "AES-256-GCM", "key_id": key_id, "ciphertext": ciphertext, "tag": tag } resp = requests.post(f"{API_BASE}/crypto", json=payload, headers=headers, timeout=10) if resp.status_code == 200: return resp.json()["plaintext"] elif resp.status_code == 422: raise ValueError("完整性校验失败，数据可能被篡改或tag错误") else: raise RuntimeError(f"decrypt failed: {resp.status_code} {resp.text}") plain = decrypt_field(result["ciphertext"], result["tag"], "key-user-mobile-prod")

这段代码可以直接整合到你的用户服务里，在写入数据库之前加密，在读出之后解密。建议把这些方法封装成独立的加密服务模块，业务层只调用encrypt_field和decrypt_field，不需要感知底层API细节，后续换服务商时只改一个模块。

3.3 进阶：密钥轮换与权限隔离

生产系统运行一段时间后，密钥轮换是迟早要面对的事。直接把旧密钥停用通常不可行，因为历史数据是用旧密钥加密的，停掉就解不开了。

正确的方法是“新旧并轨”式轮换：在KeyVault API里创建一个新版本密钥，标记为当前活跃版本；新加密的数据全部使用新版本；解密时先按密文旁记录的key_version找到对应版本密钥。

下面这个表描述了我常用的轮换策略：

执行切换时，别把切换逻辑做成“要么全切，要么不切”的硬操作，建议先在一个非核心模块试用几天，观察日志中解密失败率是否异常。这里最常见的坑是：加密时没记录key_version，导致轮换后原先的密文找不到对应密钥，最终只能离线暴力找回。所以从第一天起就养成记录key_version的习惯，哪怕老版本密钥已经退役，也要保留其解密权限直到所有对应密文完成迁移。

权限隔离方面，我建议把所有加密API的访问凭证按环境彻底分开，并且按照最少权限原则分配。开发人员只需要测试环境的加密和解密权限，生产环境的解密权限仅授予线上应用服务专用账号和极少数的安全运维负责人。

3.4 组合实践：HashGuard实现接口防重放与篡改检测

很多前后端分离项目，接口请求体被恶意篡改是个头疼问题。HashGuard API配合SecureTransmit API可以形成一套轻量的防篡改机制。

大致流程是：

1. 服务端提前把HashGuard的HMAC密钥配置给合法调用方。
2. 调用方构造请求参数后，使用HMAC-SHA256计算签名，把签名放在Header中。
3. 服务端收到请求后，调用HashGuard API用相同密钥对参数重新计算签名，比对是否一致。
4. 同时校验时间戳，超过允许时间偏差（比如5分钟）的请求直接拒绝，防止重放。

import hashlib import hmac import time import requests def sign_request(params: dict, secret: str, timestamp: str) -> str: """ 对请求参数做HMAC-SHA256签名。 注意：先把参数按key排序后拼接成字符串，避免字典序差异导致签名不一致。 """ sorted_keys = sorted(params.keys()) raw = "&".join([f"{k}={params[k]}" for k in sorted_keys]) raw += f"&timestamp={timestamp}" return hmac.new(secret.encode(), raw.encode(), hashlib.sha256).hexdigest() timestamp = str(int(time.time())) params = {"user_id": "u12345", "amount": "99.9"} secret = os.environ.get("HASHGUARD_HMAC_SECRET") signature = sign_request(params, secret, timestamp) resp = requests.post( "https://your-api.example.com/v1/order", json=params, headers={ "X-Timestamp": timestamp, "X-Signature": signature } )

服务端验证逻辑中，如果签名不一致，优先排查“参数排序规则不一致”和“编码格式不一致”这两个最常见原因。JSON的键顺序不固定，直接把JSON字符串塞进签名里是新手最容易犯的错误，正确做法是把参数转成规范化的KV串后再签名。

这套组合方案的成本几乎为零，但能挡住大量自动化脚本的恶意篡改尝试，非常值得在生产接口中落地。

4. 常见问题与排查技巧实录

使用加密API的过程中，我记录了不少真实踩过的坑。下面这些问题，几乎每一条都在线上环境真实发生过，整理出来供你对照排查。

4.1 加密性能开销过大怎么办

加密API本身响应很快，但很多时候瓶颈不在API，而在调用方式。最典型的问题是“循环里逐条加密”，比如在一个包含100条用户数据的列表循环里，逐条调用加密API，每条一次网络往返，100条数据就是100次串行请求，耗时轻松过秒。

优化方案是批量加密接口。绝大多数加密API都提供批量能力，一次传入不超过100条的明文列表，服务端批量处理后一次性返回。实测下来，批量化可以把整体耗时从秒级降到百毫秒级。另一个思路是把“必须实时加密”改成“异步加密”：主流程先把明文短暂写入暂存区，由后台任务统一拉取加密后再写入正式存储。这两种方式结合起来，性能问题基本可以解决。

4.2 密钥泄露了怎么确认和处置

首先说怎么发现。KeyVault API这类服务通常都有异常调用告警功能，比如“短时间内大量解密操作”“异地IP调用”“非工作时间调用”等规则，建议全部开启。你还可以配置一个“蜜罐密钥”——一个没有实际数据与之关联的密钥，并为其设置调用告警，一旦有人使用蜜罐密钥，几乎可以断定密钥已经泄露。

确认泄露后的应急预案分三步走：第一步，立即在密钥管理系统中吊销泄露的密钥；第二步，用新密钥对受害范围内的数据做整体重加密。实操时不要全部重加密后再切换，而是先用新密钥加密新写入数据，切换期为旧密钥保留解密权限，同时后台任务按批次重加密存量数据；第三步，追溯审计日志，梳理泄露密钥可能访问过的数据范围，评估影响，决定是否需要通知相关方。

4.3 API限流与配额超限

免费API基本都有配额限制，常见的是“每日调用次数上限”“每分钟调用次数上限”“单次请求体大小上限”。我之前被限流坑过一次，某天业务量突增，加密接口在高峰期偶发429状态码，结果部分用户入库的是明文。排查了半天，发现是API调用方完全没有处理限流重试逻辑，又因为代码里没有做“加密失败则拒绝写入”的保护性判断，导致失败静默降级。

解决思路有三层：第一层，在调用方实现指数退避重试，初次失败后等待1秒、2秒、4秒递增重试，最大重试3次；第二层，在应用层做本地熔断，连续失败超过阈值后快速失败，防止打满API配额；第三层，在写入数据库前判断加密结果，加密失败直接抛异常，绝不把明文写进落库字段。这三层同时生效，才有足够的安全感。

4.4 常见问题速查表

5. 选型时的注意事项与个人心得

最后聊一些相对主观但很重要的经验。我见过很多团队选加密API时只盯着“加密算法强不强”，其实在真实场景里，算法安全性大家基本拉不开差距，拉开差距的是易用性、稳定性和密钥管理能力。

第一，优先选择支持密钥托管的API。有人会对“托管密钥”心存顾虑，觉得密钥放在别人那不安全。但从实际运营角度，密钥托管服务通常比小团队自己管理密钥更安全，因为他们有更严格的物理安全、访问控制、审计机制。关键是看谁在管，而不是管在哪里。当然，对密钥主权要求极高的场景，选择“自带密钥”模式即可。

第二，确认API的合规能力。部分行业有明确的数据加密合规要求，比如金融、医疗、教育领域。免费API可能不会提供完整的合规报告、数据驻留位置声明。在选型前，把合规团队拉进来一起评审，别等到审计时才发现问题。

第三，不要把加密API当成全部安全方案。加密解决的是数据保密性和完整性，但安全还包括身份认证、访问控制、漏洞管理、日志监控、备份恢复等多个维度。加密API是地基，不是墙。

第四，一定要做常态化的密钥轮换演练。不要只在安全事故后轮换，平时就定期演练，比如每季度手动轮换一次非核心模块的密钥，验证流程是否顺畅。演练能暴露出文档缺失、权限遗漏、代码耦合等平时看不到的隐患。

我个人在实践中的一个体会是：加密API的最佳姿势是“透明”。业务代码不应该到处散落加解密逻辑，而是收敛到独立的加密SDK或服务模块里。这样密钥轮换、算法升级、服务商替换都只影响一个模块，不影响业务主干。透明还意味着可观测，每次加解密操作都要有日志、有指标、有告警，这样真出了问题，你可以快速定位，而不是在茫茫代码里猜。

从入门到实战，选择一款合适的加密API并不难，难的是建立一套持续运转的密钥管理和安全运维体系。先把这篇提到的六个方向吃透，再结合你的实际业务场景做二次设计，你的数据安全水位大概率能超过绝大多数同类项目。