实际场景：浏览器指纹和cookie的UUID
| 项目 | FingerprintJS visitorId bdc65ad12633d79792ceeca33a78e6c5 | 51.la 访客 ID 5a00c3da-ab80-513d-b7a7-894bcaaecf92 |
|---|---|---|
| 来源 | 读取浏览器硬件 / 软件特征，前端哈希计算 | JS 生成随机串，存入 Cookie |
| 依赖 Cookie？ | ❌ 不依赖 Cookie | ✅ 完全依赖 Cookie |
| 清除方式 | 无痕窗口、隐私插件会改变；清 Cookie 不影响 | 清除 Cookie 直接换新 ID |
| 用途 | 识别浏览器环境、风控、反爬虫 | UV 流量统计，区分新老访客 |
| 格式 | 64 位十六进制哈希bdc65ad12633d79792ceeca33a78e6c5 | UUID（四段横杠）5a00c3da-ab80-513d-b7a7-894bcaaecf92 |
重点区分：
✅ FingerprintJS 指纹：绑定【浏览器环境特征】，浏览器软件变了，特征就可能变
✅ 51.la 那种 Cookie UUID：浏览器升级一般不会清除 Cookie，UUID 不变
2026 新 MES 主流趋势：UUIDv7 > ULID > 雪花 Snowflake
一句话结论：
新项目、车间多终端、多产线采集、跨系统对接 MES，优先 UUIDv7（RFC9562，IETF 标准）； 如果你数据库坚持要
BIGINT数字主键、超高写入，保留雪花 ID； 需要短字符串条码 / 对外展示，选 ULID。
你之前理解的 “字符串拼接流水号”，属于老一代土办法，已经不推荐做主键，只适合单独业务条码。
三个方案横向对比（MES 场景重点）
表格
| 方案 | 存储 | 核心优点 | MES 痛点 | 适合场景 |
|---|---|---|---|---|
| UUIDv7（2026 新标准） | 16 字节 (128bit)，数据库原生 UUID 类型 | ✅ IETF 国际标准；时间有序；不需要维护 WorkerId；不用分配机器号；时间回拨风险极小；跨产线、跨工厂、多采集终端随便生成；兼容所有支持 UUID 的数据库；.NET 9 + 原生支持 | 占用 16 字节，比雪花 8 字节大一倍；字符串 36 字符 | 新建 MES 项目首选；工单、报工、设备采集、追溯记录；多工厂分布式部署；PLC / 采集终端本地生成 ID，不用协调节点 ID |
| ULID | 16bit 底层，对外输出 26 位 Base32 字符串 | ✅ 时间有序；26 字符短串，大小写不敏感，适合条码；没有 UUID 的横杠；同样不需要 WorkerId | 非 IETF 标准，属于社区规范；数据库没有原生 ULID 类型，一般存字符串 | MES 需要 ID 直接当条码、对外打印、对接第三方系统；不想带 UUID 的-分隔符 |
| 经典雪花 Snowflake | 8 字节 BIGINT long | ✅ 体积最小，索引、JOIN 性能最好；百万级高并发写入 | 最大坑：WorkerId 分配 + 时钟回拨。MES 车间几十台采集机、多应用实例，一旦 workerId 重复直接 ID 冲突；NTP 时间回退会报错。需要额外服务 (Zookeeper/Redis) 分配机器 ID | 老 MES 升级、必须数字主键、单工厂高吞吐，产线节点数量可控，运维能管住服务器时钟 |
为什么 UUIDv7 是现在 MES 的新趋势？
雪花最大的麻烦，在 MES 车间场景被放大： MES 不只是后台服务，车间有大量独立采集终端、工控机、边缘网关。 雪花必须保证每台机器 workerId 唯一，你要做：
- 部署时分配 workerId
- 新增产线 / 新增采集机要登记
- 机器重装、IP 变动容易重复
- NTP 同步时间回拨，直接报异常，车间生产数据不能丢
UUIDv7：没有 WorkerId！ 结构：48 位毫秒时间戳 + 版本位 + 74 位随机数。 时间放高位，ID 趋势递增，InnoDB 聚簇索引不会碎片； 随机位足够大，多节点随便生成，几乎不会碰撞，不需要任何协调服务。
本质可以理解为：标准化、免机器 ID、弱化时钟回拨风险的 128 位升级版雪花
C# .NET 实现（UUIDv7，MES 直接可用）
.NET9 内置原生Uuid.CreateVersion7()，一行代码搞定，不用自己写复杂位运算。
// .NET 9+
Guid id = Uuid.CreateVersion7();
string strId = id.ToString();
低于.NET9，用成熟开源库：UUIDv7 / IronUuid，工业项目大量在用。
ULID C# 示例（适合条码打印）
输出 26 位短字符串，无横杠，不区分大小写，适合条码、扫码枪读取。
01J92B64XQ0Z8N3G9W7S2K5F1M
MES 落地最佳实践（推荐双 ID 策略，大厂工业软件现在都这么干）
【数据库主键】UUIDv7（内部唯一、有序、跨工厂分布式，省心） 【业务条码 / 对外编号】单独生成 ULID / 自定义流水号（给车间扫码、对接 ERP、客户）
不要把主键直接拿来当条码！主键是数据库内部身份；条码是业务对外标识，两者职责分开。
选型决策树，直接对照你的 MES 项目
- 全新开发、多工厂、大量边缘采集终端、不想维护 workerId、怕时间回拨 → UUIDv7（首选）
- 必须 BIGINT 数字主键、单工厂、并发极高，运维能严格管控服务器时钟 → 雪花 ID
- 需要 ID 直接打印条码，短字符串、无横杠、扫码友好 → ULID
- 简单小 MES，单机，没有多节点 → 自增 ID 足够
💥💥💥💥💥💥💥💥💥💥
核心一句话
“适合” 是可行性集合（一堆方案都能满足业务底线，70% 匹配）；“最好” 是在你这套项目的约束条件下，单一最优解。 矛盾并不存在：适合 = 及格；最好 = 及格里面第一名。
拆开理解你说的两点
- 适合（70% 匹配） 只要能满足基础需求：全局唯一、并发不冲突、可落地、维护成本可控，就算 “适合”。 雪花、UUIDv7、ULID、自增 ID，甚至你手写的时间拼接流水号，都可以做到 70% 适配 MES。 它们都能生成唯一编号，存入数据库，给工单 / 报工做主键。
所以你会感觉：可选方案一大堆，好像哪个都能用。这就是【适合的很多】。 但这 70 分只是保底，剩下 30 分，来自项目独有的硬性约束，约束会淘汰所有选手，只留下一个 “最好”。
- 最好（唯一） “最好” 不是绝对世界第一的 ID 算法，而是在你固定约束下的最优。 没有脱离场景的 “最好 ID”；一旦约束清单定死，最优解就收敛到唯一。
举个 MES 的例子： 约束列表（权重从高到低） ① 车间几十台边缘工控机，不能引入 Redis/ZK 去分配节点 ID（运维拒绝，车间工控机不能依赖中心服务） ② 数据库 MySQL InnoDB，主键需要有序，避免页分裂 ③ 主键用于数据库关联查询，但不需要直接打印成条码 ④ 项目是.NET8，不能升级到.NET9 ⑤ 不希望处理时钟回拨的异常兜底逻辑
过滤：
- 经典雪花：需要 workerId 分配，违反① → 淘汰
- UUIDv4：无序，违反② → 淘汰
- ULID：可以，但数据库没有原生类型，存储处理麻烦，对比 UUIDv7 劣势 → 淘汰
- UUIDv7：满足全部约束 → 这就是唯一最好
如果改一条约束，最优直接变：
约束改成：数据库强制要求 BIGINT 数字主键，不能用 16 字节 Guid 那 UUIDv7 直接出局，雪花就变成这个场景里唯一最好。
本质：为什么会出现 “一堆适合，但最好只有一个”
- 适合看【能力】，最好看【代价】 所有适合的方案，能力上都能完成生成唯一 ID 这件事。 但代价不一样：开发成本、运维成本、故障风险、性能损耗、后期扩展风险。
70 分是 “能干”；剩下 30 分全部是各种隐性代价。 最好的那个，就是总分最高，且没有致命短板。
- 适合是 “正向满足需求”；最好是 “规避你项目独有的致命风险” MES 里最大风险不是 “能不能生成 ID”，而是生产中断、数据重复、车间工控机故障。
- 如果你车间 NTP 经常乱跳，雪花的【时钟回拨】就是致命风险 → 雪花哪怕 80 分，直接出局
- 如果你系统只能用 SqlServer 旧版本，不支持 Guid 优化，UUIDv7 的存储开销就是致命短板
很多选型误区：只对比优点，不看自己业务不能接受的缺点。 只要有一个不可接受的硬缺陷，哪怕其他方面再优秀，直接从候选名单剔除。
实操方法论：MES 选型打分法（解决这个矛盾）
不要凭感觉，列权重表，算总分，自然得到唯一 “最好”
- 列出你的硬性红线（一票否决项） 例： ✘ 不能依赖中心服务 ✘ 数据库必须 BIGINT ✘ ID 需要直接打印条码 只要不满足红线，直接淘汰，不再参与打分。
- 剩下的就是一堆 “适合” 的候选（70% 以上匹配）
- 给剩余维度设置权重（按你的项目优先级） 比如：
- 分布式多终端部署难度：30%
- 数据库索引性能：25%
- 故障风险（时钟回拨 / ID 冲突）：25%
- 开发维护成本：20%
- 逐项打分，加权求和，最高分就是当前场景下唯一的最好方案
重点：换项目，权重和红线变，“最好” 就会变。 不存在放之四海而皆准的最好 ID，只存在当前约束下的最好 ID。
回到你 MES 的场景，简单总结
所有 ID 算法，都可以做到 “能用”（适合，70 分）。 但当你把：数据库类型、边缘采集终端数量、运维能力、是否允许引入中间件、是否要打印条码、.NET 版本、并发量、可接受故障风险，全部固定下来之后，最优解就只剩一个。
你可以把你的 MES 这几条约束告诉我，我们直接走这套打分，算出对你项目唯一的那个最优 ID 方案：
- 数据库：MySQL / SQLServer？版本？主键字段类型是否可以自定义？
- 终端：多少台边缘工控 / 采集机？能不能跑 Redis/ZK？
- .NET 版本？
- ID 用途：仅数据库主键？还是主键要直接当条码打印？
- 车间服务器 / 工控机 NTP 时间同步是否稳定？
💥💥💥💥💥💥💥💥💥💥
核心结论
能兼容全部这些数据库，但没有免费的午餐；想要「跨库兼容 + 写入快 + 查询快」，主键类型必须做取舍，并且要区分：逻辑 ID（业务唯一标识） vs 物理主键（各库内部主键）。
先把你列的清单：MySQL、SQLServer、PostgreSQL、Oracle、TDengine（涛思）、MongoDB、Redis。
重点：不要把同一个 ID 直接当成所有库的物理主键，这是很多跨平台 MES 踩的大坑。
先逐个看各数据库对 ID 类型的原生支持
1）64 位数字（雪花 long）
- MySQL：
BIGINT✅ - SQLServer：
BIGINT✅ - PostgreSQL：
BIGINT✅ - Oracle：
NUMBER(19)✅ - TDengine：
BIGINT✅（时序库，非常适合 MES 采集流水） - MongoDB：可以存 NumberLong ✅；但 Mongo 原生
_id是 ObjectId，混用没问题 - Redis：存数字字符串 /long ✅
✅ 优点：体积最小（8 字节）、写入、索引、关联查询性能天花板 ❌ 致命短板：
- 分布式多节点需要 WorkerId，时钟回拨风险；
- 跨系统、跨工厂合并数据时，ID 冲突风险高；
- 虽然各库都能存 BIGINT，但 Oracle NUMBER (19) 性能略弱于原生整数；
- 最重要：TDengine、Mongo、Redis 本身业务场景，数字 ID 不是天然优势。
关键：BIGINT 全库都能存，但跨集群多工厂场景下，ID 冲突风险是业务风险。
2）UUIDv7（128bit，Guid）
- MySQL：
UUID类型 (8.0+) /char (36)；推荐二进制binary(16)✅ - SQLServer：
UNIQUEIDENTIFIER✅ - PostgreSQL：
uuid原生类型 ✅ - Oracle：
RAW(16)或者VARCHAR2(36)✅ - TDengine：没有原生 uuid 类型，只能存
BINARY(16)或者字符串 ✅ - MongoDB：直接存 Guid/Binary ✅
- Redis：存二进制或者字符串 ✅
✅ 优点：跨库、跨工厂、边缘设备随便生成，不需要协调节点 ID，全局几乎不会冲突。 ✅ 有序（高位时间戳），InnoDB、PG、Oracle 聚簇索引友好，写入不会疯狂页分裂。 ❌ 缺点：16 字节，比 long 大一倍；Oracle、TDengine 用 binary 存储需要小心处理编码；字符串形态（带横杠 36 字符）索引性能暴跌，必须存二进制。
3）ULID（26 位 Base32 字符串）
所有库都只能当字符串存储：VARCHAR(26) ✅ 无横杠、适合条码；字典序和时间序一致。 ❌ 硬伤：所有数据库都是字符串类型，索引性能低于 BIGINT / 原生 UUID 二进制。
跨库兼容最省事，但写入、查询性能最差，不适合海量时序采集数据（TDengine）。
矛盾点：你要求【兼容全部 7 种存储 + 写入快 + 查询快】
现实约束
- BIGINT (long)：性能最强，但分布式冲突风险高 适合：单工厂、节点可控。 不适合：多工厂、大量边缘终端，跨库合并数据。一旦两套系统生成相同 workerId，ID 重复，数据灾难。
- UUIDv7（二进制存储）：兼容性 + 性能综合最优，是你这个场景的首选
- 跨所有数据库都能落地；
- 二进制 16 字节，性能接近 BIGINT，远好于普通字符串；
- 无需 workerId，边缘机、多工厂随便生成，无协调依赖；
- 时序库 TDengine 用
BINARY(16)存储，Mongo 存 Binary，Redis 可以存二进制。
但有个代价：每个数据库必须做类型适配，不能直接统一用字符串形式。 👉 二进制存库，对外业务传输可以转字符串（
ToString()），内外分离。
❌ 禁止：把带
-的 36 位 UUID 字符串直接当主键存到所有库，写入查询都会明显变慢。
方案架构推荐（跨多存储 MES 标准做法：双 ID）
【物理主键】：每个数据库内部自己的自增 / 原生主键（仅数据库内部使用，对外不暴露） 【业务全局唯一 ID】：UUIDv7（二进制存储），作为业务唯一 Key，所有系统、所有存储统一使用这个 ID，用于关联、跨库查询、MES 单据、报工、采集数据。
好处：
- 所有存储（MySQL/SQLServer/PG/Oracle/TD/Mongo/Redis）都能存储这个业务 ID；
- 业务表之间关联，统一用这个 UUIDv7；
- 数据库内部物理主键不受影响；
- 边缘设备离线也可以生成 ID，不需要依赖 Redis/ZK。
各库存储 UUIDv7 的最佳存储方式
表格
| 存储 | 推荐字段类型 | 说明 |
|---|---|---|
| MySQL 8.0+ | BINARY(16) | 不要 char (36)，性能差很多 |
| SQLServer | UNIQUEIDENTIFIER | 原生支持，有序 UUIDv7 在新版 SQLServer 索引友好 |
| PostgreSQL | uuid | 原生类型，性能很好 |
| Oracle | RAW(16) | 不要 VARCHAR2 (36) |
| TDengine（涛思时序库） | BINARY(16) | 时序采集数据量大，二进制占用低 |
| MongoDB | Binary | BSON Binary，不要字符串 |
| Redis | 二进制字节数组 / 16 字节 bytes | 比字符串更省内存 |
传输层（API、MQ、消息队列、日志）：UUIDv7 转 36 位字符串传递；落库全部转二进制。
什么时候不能选 UUIDv7？
只有一个硬红线：数据库强制要求必须是数字类型主键，不能使用二进制 / Guid。 一旦这条红线存在，你只能退回到雪花 BIGINT，并且要承担 workerId 分配、时钟回拨、跨工厂 ID 冲突风险。
性能对比（写入 & 查询）
- BIGINT 雪花：⭐⭐⭐⭐⭐（8 字节，最优）
- UUIDv7 二进制：⭐⭐⭐⭐（16 字节，差距不大，海量数据才会拉开差距）
- ULID 字符串：⭐⭐⭐（VARCHAR，最差）
千万级数据场景：UUIDv7 二进制性能衰减很小；亿级时序数据（TDengine），BIGINT 会更占优，但代价是分布式 ID 冲突风险。
额外两个坑，MES 跨多存储必看
- 字节序 / 大小端问题 Guid 在 C# 和 Oracle、TDengine 之间转二进制的时候，.NET 的 Guid 内部字节顺序和部分数据库不一致。 解决方案：不要直接
Guid.ToByteArray()直接入库，要按标准 RFC9562 的字节顺序重新排列，否则同一条 ID，在不同库二进制不一样，跨库查不到。 - TDengine 时序场景 TDengine 的超级表，tag 和 timestamp 是核心。业务 UUIDv7 一般作为普通字段，不要做主键（时间戳才是 TDengine 主键）。很多人在这里踩坑，把业务 ID 当成时序库主键，查询直接崩。
最终选型一句话
你的需求：多数据库异构、跨库、边缘采集、写入查询兼顾 👉 最优：UUIDv7，传输用字符串，落库统一存储 16 字节二进制 仅当业务硬性强制必须数字主键，才退化成雪花 BIGINT，并且接受它的运维代价和 ID 冲突风险。
如果你需要，我可以给你 C# 的工具类：
- UUIDv7 生成 + RFC9562 标准二进制序列化（解决.NET Guid 大小端跨库不一致问题）
- 统一方法：输入 Guid，输出适合 MySQL/Oracle/TDengine 的 byte []。
要不要这个工具类？
💥💥💥💥💥💥
我刚才问的问题，还有什么不足或者不专业的地方?
先说结论：你的提问思路方向没问题，是工程落地视角，但存在几处典型的「业务概念混同、约束模糊、数据库原理认知简化」，属于工业软件（MES）开发选型里很常见的不专业点，我逐条拆开，同时告诉你专业上该怎么表述。
1. 最大问题：把【全局业务 ID】和【数据库主键】混为一谈（最核心）
你的原话：
这个id，要兼容多种数据库，redis，mysql，sqlserver，postgresql，oracle，涛思数据，mongodb，可行吗，查询快，写入要快
不专业点
你默认：同一个 ID，在所有这些存储里面，都直接作为表的主键。 但这些数据库的主键设计范式本身就不一样：
- TDengine（涛思）：主键是时间戳 + 标签，业务 ID 根本不适合做主键，业务 ID 只能作为普通字段（用于过滤、关联）；
- MongoDB：内置
_id是 ObjectId，你可以存自定义 ID，但它是文档库，和关系库聚簇索引逻辑完全不同； - Redis：它不是数据库表，是 KV 缓存，Redis 没有 “表主键” 概念，ID 在这里是key 或者 value 里的业务索引字段。
✅ 专业表述区分两个概念：
- 业务全局唯一标识（Business Global ID）：跨所有存储、跨系统唯一，用于单据关联、追溯、MQ 消息、跨库检索；它不一定是各库的物理主键。
- 各存储内部物理主键：每个数据库自己选最优主键，可以不一样，只服务这个库内部存储。
很多踩坑项目，就是强行把同一个 ID，在 TDengine、Mongo、Oracle 全部当成主键，时序库性能直接崩盘。
2. 需求描述缺少「量化指标」，属于定性描述（工程评审会被质疑）
描述：
查询快，写入要快
不专业点
“快” 是主观词，没有量化，无法做选型评估。
- 写入：每秒多少条？峰值多少？是单条写入还是批量？TDengine 时序采集是百万级 / 小时，和工单表完全不是一个量级；
- 查询：是按 ID 单点查询，还是范围分页、模糊查询、多条件联合查询？MES 绝大多数场景是按 ID 单点查询，但时序库是按时间范围；
- 数据量级：表预估多少行？千万？亿级？不同量级下，BIGINT / UUIDv7 的性能差距权重完全不一样。
✅ 专业写法示例：
业务全局 ID，支持跨 MySQL/SQLServer/PG/Oracle/TDengine/MongoDB/Redis 存储； 单点按 ID 查询响应 < 5ms； 峰值写入 2000 TPS； 预估单表最大 1 亿行； 支持边缘端离线生成 ID，无中心协调服务。
3. 忽略：不同存储的索引实现差异，笼统说 “查询快”
关系库（InnoDB）是聚簇索引；PostgreSQL 是堆表 + B 树；Mongo 是 B 树索引；TDengine 是时序分区 + 时间索引。 同一个 ID，在不同库，索引收益完全不一样。
- UUIDv7 二进制：在 MySQL/PG/SQLServer 很好；但 TDengine 里，它只是普通二级索引，不能替代时间作为主索引；
- BIGINT 雪花：数字索引在关系库很强，但 Mongo 的数字索引、Redis 的 key，收益场景不同。
误区：认为 ID 类型本身决定 “查询快”；真实是：ID 类型 + 该库的索引结构 + 查询模式共同决定性能。
4. 把 Redis 和其他数据库并列放在同一层级，概念层级不对
mysql，sqlserver，postgresql，oracle，涛思数据，mongodb，redis
不专业点
分类混淆：
- 关系型数据库：MySQL、SQLServer、PostgreSQL、Oracle
- 时序数据库：TDengine（涛思）
- 文档数据库：MongoDB
- Redis：分布式缓存，不是持久化主数据库（当然也可以做持久化，但定位不是业务主存储）
工程上不会把 Redis 和业务数据库并列，它一般用来：缓存业务 ID、分布式锁、计数器、临时索引；不会用来存全部 MES 主业务数据。 专业上会分开描述：持久化存储清单 + 缓存中间件。
5. 缺少两类关键约束（异构系统 ID 选型必问）
你只提了数据库兼容、读写性能，漏掉两个 MES 异构场景的硬性约束：
- ID 的传输与对外展示约束 是否需要对外打印条码、给到 ERP、WMS、第三方系统对接？
- 如果需要扫码：二进制 UUIDv7 不能直接打印，必须转字符串，这是额外的编解码开销；
- 如果只是内部系统关联：二进制没问题。
- 离线生成能力 车间边缘采集机断网的时候，能不能本地生成 ID？ 雪花需要协调 workerId，离线多节点会冲突；UUIDv7 可以离线生成。
这两个是 MES 选型里权重很高的红线，不提的话，选型结论是不完整的。
6. 一个认知误区：“ID 兼容所有数据库” 的理解偏差
很多人理解成：同一套字段定义，直接在所有库建表，一字不改。 这是几乎做不到的。 专业理解是：同一个业务 ID 逻辑值，可以在不同存储选择该库最合适的原生类型存储，而不是所有库统一字段类型。
例如同一个 UUIDv7：
- SQLServe- SQLServer：UNIQUEIDENTIFIER
- MySQL：BINARY(16)
- Oracle：RAW(16)
- TDengine：BINARY(16)
- MongoDB：Binary
- Redis：byte [] 逻辑 ID 完全相同，只是各库存储类型适配，不是统一 VARCHAR (36) 全库跑。
7. 风险维度缺失：没有考虑数据迁移、数据合并、灾备场景
MES 项目经常有：多工厂合并、数据迁移、灾备同步、历史数据归档。
- 雪花：多工厂合并极易 ID 冲突；
- UUIDv7：跨工厂合并天然安全，但二进制跨库迁移要处理字节序陷阱； 你需求里完全没有提到数据合并、归档、跨库数据同步，这是工业软件非常核心的场景。
精简总结（你提问里的薄弱点清单）
- 混淆【业务全局 ID】vs【数据库物理主键】，误以为 ID 必须在所有库当主键；
- 性能需求只有定性描述（读写快），缺少量化 TPS、数据量、查询模式；
- 存储分类不严谨：Redis 是缓存，不是主数据库，和 TD/Mongo/ 关系库不是同一层级；
- 没有给出业务边界：是否需要条码、边缘离线生成；
- 假设所有数据库可以用完全一样的字段定义存储同一个 ID；
- 缺少长期运维场景评估：多工厂数据合并、归档迁移、灾备同步。
优化后的专业提问模板（你以后技术评审可以直接用）
需求：设计一套全局业务唯一 ID，用于 MES 跨系统关联。 持久化存储包含 MySQL、SQL Server、PostgreSQL、Oracle、TDengine、MongoDB；使用 Redis 做缓存。 约束：
- 边缘采集节点断网时可本地生成 ID；
- 单点按 ID 查询响应 <5ms，峰值写入 2000TPS；单表最大 1 亿行；
- 支持多工厂后期数据合并、归档；
- ID 仅用于系统内部关联，不需要直接打印条码； 请评估候选 ID 方案（雪花 / UUIDv7 / ULID），给出推荐方案、各数据库存储类型、潜在风险。
