企业官网建设流程全解析

1. 从“一个组件”到“一套渲染链路”

很多人第一次接触鸿蒙版 React Native，都会下意识地认为：既然 OpenHarmony 提供 ArkUI 组件，那直接把 RN 的 Text 映射到 ArkUI 的 Text 不就行了？听起来好像没毛病，但实际做起来远没有这么简单。Text 在 RN 里不是简单的“显示字符串”的组件，它承载了样式体系、嵌套规则、事件冒泡、文本测量、截断逻辑、国际化排版等一系列能力。你把它映射到 ArkUI 的 Text 上，只是完成了第一步，后面还有一整套参数转换、属性映射、布局计算、事件桥接的活儿要干。

我参与某跨平台系统在 OpenHarmony 上的适配时，最初版本就是用最简单的一对一映射：RN 的 Text 对应 ArkUI 的 Text，style 里的 fontSize 直接转成 ArkUI 的 fontSize，color 直接转成 color。跑起来倒是能显示，但一旦遇到嵌套文本、行高不一致、字体加粗偏差、文本溢出省略号位置不对等问题，就开始各种不对劲。后来我意识到，问题的根源在于：RN 的 Text 渲染哲学和 ArkUI 的 Text 渲染哲学，压根儿不是一回事。

RN 的文本模型是“虚拟文本树”：一个 Text 可以包含多个嵌套 Text，每个嵌套 Text 有自己的样式，最终由 Yoga 引擎统一计算布局，再交给宿主平台渲染。而 ArkUI 的 Text 虽然也支持富文本，但它的属性体系和事件体系跟 RN 不是一一对应的。你要做的不只是“翻译”，而是“适配”——在两层架构之间建立一套转换规则，同时保证布局结果一致、点击区域准确、性能可接受。

所以这篇文章我想讨论的核心，不是“怎么把 RN Text 换成 ArkUI Text”，而是“RN Text 的渲染哲学在 OpenHarmony 上怎么落地”。我会从渲染链路的整体设计、布局测量、样式映射、事件处理、性能优化、以及我实际踩过的坑这几个维度展开，尽量把每个环节背后的为什么说清楚。

阅读对象：正在做 OpenHarmony 原生适配的开发者、准备评估 RN 跨端方案的团队、对 ArkUI 渲染机制感兴趣的工程师。如果你只是简单调用 RN 的 Text 组件写业务，那这篇文章可能偏底层，但如果你遇到过诡异的对齐问题、文本测量异常、截断位置不对，那这篇文章里的排查思路应该能帮到你。

2. 渲染哲学：RN 的布局模型和文本模型

2.1 Yoga 布局引擎的文本测量机制

RN 在鸿蒙上的渲染，底层依赖的布局引擎和 iOS/Android 上一样，都是 Yoga。Yoga 本身不负责真正的文本排版，它只负责计算“文本节点应该占用多大区域”。那这个区域大小怎么来？Yoga 会调用平台提供的文本测量接口，输入一串文本、一组样式约束（宽度、字体大小、行高、字重等），然后拿到宽高和行数信息，再基于这些数据完成布局。

这里有一个关键点：Yoga 的文本测量必须和最终渲染结果保持一致。如果测量结果是 100 宽，但 ArkUI 实际渲染出来是 98 或者 102，那么整个布局就会偏移、错位、截断异常。所以做 RN 鸿蒙适配时，最核心的任务之一，就是保证“测量”和“渲染”用的是同一套文本排版规则。

我在实现中采用的方式是：自定义了一个文本测量适配层，底层调用 ArkUI 提供的测量接口，传入 fontSize、fontWeight、lineHeight、letterSpacing 等参数，拿到准确的文本宽高。但这里面有一个细节特别容易忽略——默认字体。RN 在每个平台都有自己的默认字体族，iOS 是系统字体，Android 是 Roboto，Web 是系统默认字体。鸿蒙上如果你不显式指定字体，ArkUI 会用 HarmonyOS Sans，这个字体和 Roboto 的字宽、字重表现都存在差异。哪怕你 fontSize 设的一样，实际测量结果可能偏差几个像素，布局就可能不对。

我的处理策略是：在适配层初始化时，统一设置默认字体族，保证 RN 侧不显式设置字体的文本，和 ArkUI 渲染时使用的字体一致。这一步不做，后面所有文本对齐都会是“薛定谔的对齐”——有时候对，有时候不对。

2.2 嵌套文本的“继承”和“覆盖”语义

RN 的 Text 支持嵌套，比如：

<Text style={{ fontSize: 20 }}> 外层文本 <Text style={{ color: 'red' }}>红色内层</Text> </Text>

内层 Text 会继承外层的 fontSize，只覆盖 color。这个继承语义，在 ArkUI 的 Text 里没有直接对应的模型。ArkUI 的富文本是 Span 模型，每个 Span 节点需要显式设置样式，不存在“继承父节点样式”这个说法。

所以在适配层，我需要做一次“样式拍平”：遍历 RN 的 Text 树，从根节点开始逐层收集样式，内层节点只保留自己显式声明的样式，其余从父节点继承。拍平之后，再按顺序生成 ArkUI 的 Span 数组，每个 Span 带完整的样式。

这个拍平过程，除了样式继承，还要处理几个边界情况：

• 文本节点的文本内容可能分多段，有的段落在内层 Text 之前，有的在内层 Text 之后，段落顺序不能乱。
• 内层 Text 可能还嵌套内层 Text，递归深度要控制好，避免极端场景下栈溢出。
• 内层 Text 的事件（比如 onPress）要单独标记，不能和外层混淆，否则点击区域会错。

这些边界情况，我在第一版里没处理全，结果遇到了一个很头疼的问题：文本中间有内层 Text 时，内层 Text 前后的段落被合并成了同一个 Span，样式互相污染，文本颜色整段变红。后来花了一个下午梳理递归逻辑，才把顺序问题彻底解决。

2.3 行高和基线对齐的坑

行高是文本布局里最磨人的参数。RN 的 lineHeight 语义，和 ArkUI 的 lineHeight 语义存在差异。RN 里 lineHeight 是基于字体度量计算的行框高度，而 ArkUI 的 lineHeight 也是行高，但两者的默认值、计算基准、以及和 fontSize 的配合方式不完全一样。

举个例子：RN 中 fontSize=20、lineHeight=30，在 Android 上文本的整体高度基本就是 30 * 行数。但在鸿蒙上，如果你直接把 lineHeight 传给 ArkUI，可能测量出来的整体高度比 30 * 行数小几个像素，或者大几个像素。原因在于默认字体不同、字体度量不同、以及行高的分配方式不同。

解决这类问题，我最后没有靠手动微调，而是直接在测量层做了基准对齐：统一把 lineHeight 作为布局高度基准，渲染层也严格使用相同的 lineHeight，并在适配层做一次文本基线偏移补偿。实测下来，多行文本的布局高度误差控制在 1 像素以内，整体对齐就稳定了。

这里给一个排查建议：如果你的 RN 文本在鸿蒙上出现“底部多了一截空白”或者“垂直居中偏上”，优先检查 lineHeight 是不是被重复计算了。常见的情况是，适配层传了 lineHeight，ArkUI 内部又根据 fontSize 计算了一个默认行高，两边叠加导致高度异常。解决办法就是显式统一基准。

3. 工程实现：从 RN Shadow Tree 到 ArkUI 渲染节点

3.1 三层架构的总体设计

RN 在 OpenHarmony 上的整体渲染链路，我习惯把它分成三层：

• JS 业务层：也就是业务代码写的 React 组件树，RN 的 Text 在这里声明。
• Shadow Tree 层：Yoga 布局计算后的虚拟节点树，每个节点携带布局结果和样式信息。
• 原生渲染层：OpenHarmony 侧的 ArkUI 组件树，最终把内容画到屏幕上。

我们适配团队的工作，主要就是第二层到第三层的桥接。RN 官方框架在 Android/iOS 上已经有成熟的桥接实现，但在 OpenHarmony 上需要重新实现一套。Text 组件的适配，本质就是实现一个 Fabric 风格的 Native Component：接收 Shadow Tree 的 Props，转换成 ArkUI 的组件参数，然后创建/更新/销毁对应的 ArkUI 节点。

架构上，我采用了一个轻量级的“中间表示层”，叫它 RNTextNode 吧。每一个 RN 的 Text 组件，对应一个 RNTextNode；RNTextNode 持有拍平后的 Span 数组、文本样式、事件处理器、以及布局坐标。渲染时，RNTextNode 生成一个 ArkUI 的 Text 组件，并把 Span 数据、事件回调、坐标数据一次性绑定上去。

为什么不直接在渲染层做转换？因为 ArkUI 的组件更新是增量式的，你直接操作 ArkUI 组件，很难做 Diff 优化。中间层可以把 JS 侧的 Props Diff 结果转换成更高效的 ArkUI 更新指令。比如 RN 侧只是 fontSize 变了，ArkUI 侧只需要更新 fontSize 属性，而不需要重建整个 Text 组件。

3.2 属性映射表：一个 Props 背后的十几次转换

Text 组件的 Props 不少，常用的包括 fontSize、fontWeight、color、lineHeight、letterSpacing、textAlign、textDecoration、fontStyle、numberOfLines、ellipsizeMode、onPress、onLongPress 等。每个 Props 到 ArkUI 的映射，都有一层转换逻辑。

我整理过一个属性映射表，其中几个比较典型的：

这里面最容易出问题的，不是名称对应问题，而是“语义对应的粒度”。RN 的 textDecorationLine 是组合值，可能同时有 underline 和 line-through；ArkUI 的属性可能不支持同时设置，需要拆成多个属性组合。textShadow 也是，RN 的 textShadowColor、textShadowOffset、textShadowRadius 需要组合成 ArkUI 的 shadow 参数。

我的经验是，属性映射表一定要做成“可配置”的，不能把转换逻辑硬编码在组件代码里。每个属性写一个独立的转换函数，方便单测覆盖，也方便后续适配新版本 RN 时快速调整。

3.3 事件系统的桥接：点击、长按、文本选择

RN 的 Text 组件支持 onClick、onLongPress、onTextLayout 等事件。鸿蒙 ArkUI 组件也有对应的点击、长按事件，但事件对象的字段、坐标体系、时间戳格式都不一样。适配层的职责就是做一次事件对象转换，把 ArkUI 的事件参数包装成 RN 侧能够识别的事件结构。

这里有一个比较容易忽略的点：RN 的 Text 点击事件，支持“点击文本中的某一行”这种粒度吗？目前来看，RN 原生端 Text 的 onPress，事件对象里没有暴露具体的行号和字符位置，只有通用的事件信息。所以鸿蒙适配层也不需要额外实现行级命中，只需要保证“点击事件能触发、点击区域正确”就算达标。

但文本选择（TextSelection）不同。RN 的 Text 本身不支持文本选择，需要靠 TextInput 或者第三方组件库。OpenHarmony 的 ArkUI Text 组件原生支持文本选择，但默认关闭。适配时要注意：RN 的 Text 组件默认不应该有文本选择能力，必须显式关闭，否则会出现“点击文本弹出选择菜单”这种和 RN 行为不一致的情况。这个小细节，我第一版就漏了，测试同事反馈说“文本长按怎么有复制菜单”，我排查了半天才发现是 ArkUI 默认行为。

长按事件的坐标转换也要注意。RN 的事件坐标是基于屏幕的，ArkUI 的事件坐标是基于组件的，转换时需要把组件的位置偏移加上去。这个偏移如果拿不到，就先缓存组件的布局坐标，事件触发时再动态计算。

4. 实操过程：一步一步实现 Text 组件鸿蒙适配

4.1 搭建最小验证环境

在动手写完整适配之前，我建议先搭建一个最小验证环境，把“RN Text -> ArkUI Text”的基础链路跑通。这个环境不需要完整的 RN 框架，只需要：

• 一个 OpenHarmony 应用工程（标准 Stage 模型）
• 一个最简单的 RN 运行时壳，能加载一个 JS Bundle
• 一个测试页面，页面里只有一个 Text 组件

我当初是用一个最简单的 JS Bundle 做的验证，Bundle 里渲染一个包含嵌套 Text 的组件，然后在鸿蒙侧打印接收到的 Props 和布局结果。这一步的作用是确认：RN 框架是否正常工作、Shadow Tree 是否生成、Props 是否能正常传递到 Native 层。

在这个阶段，不要急着做复杂的样式映射，先验证基础链路。链路通了，后面所有调优才有意义。我见过一些团队，一上来就把所有属性映射都写完，结果基础链路有问题，排查起来非常痛苦，因为分不清是框架问题还是映射问题。

4.2 文本测量适配的完整实现

基础链路通了之后，第一件正事就是文本测量。

RN 在 Yoga 布局阶段，需要一个 measure 函数。这个函数输入：

• 文本内容
• 可用宽度
• 样式参数

输出：

• 文本宽高
• 行数

在鸿蒙侧，我用的是一个封装好的 TextMeasurer 类。它的核心逻辑是：创建一个离屏的 ArkUI Text 组件，设置好样式和文本，然后调用 Measure 接口，获取期望尺寸。

实现中需要注意几个细节：

• 离屏组件的宽度约束必须和 Yoga 传入的可用宽度一致，否则测量结果会有偏差。
• 字体设置必须在测量前完成，因为字体变了，测量结果就变了。
• 如果有 numberOfLines 限制，测量时也要传进去，否则文本不会被截断计算，高度会超出预期。

这段逻辑写稳之后，你会发现 RN 文本在鸿蒙上的整体布局就能对上号了。我当时的验证方法是：写一个网格背景页面，把每行文本的布局框画出来，肉眼比对文字是否落在预期区域内。

4.3 样式拍平和 Span 生成逻辑

样式的拍平逻辑，是整个 Text 适配里最核心的代码。

我的实现分成两个步骤：

第一步，递归解析。从一个 Text 节点开始，维护一个“当前继承样式”对象，初始值为父节点的样式。每遇到一个子 Text 节点，就把子节点显式声明的样式合并进当前继承样式，同时记录合并后的快照。

第二步，生成 Span。遍历解析后的节点集合，按文本顺序生成 Span。每一个 Span 包含：文本内容、样式快照、事件标记。

这里有一个很重要的优化点：如果一段文本没有任何样式差异，就不要拆成多个 Span。合并 Span 可以减少 ArkUI 侧的节点数量，提升渲染性能。我见过一种糟糕的实现，每个 Text 子节点都生成一个 Span，哪怕样式完全一样，导致一个 50 字的文本生成了 20 多个 Span，性能和内存都受影响。

生成 Span 后，还有一个环节：处理文本中的特殊字符。RN 文本里可能包含换行符、制表符、以及各类 Unicode 字符。ArkUI Span 对某些字符的支持和 RN 原生不完全一致，比如零宽空格、组合字符、emoji 变体选择符。这类字符如果处理不当，会出现文本显示缺失、重叠、或者 emoji 显示为黑白样式。我做的处理是：在生成 Span 时，对文本做一次 Unicode 规范化，同时把容易出问题的字符单独标记。

实操过程中我总结了两条经验：

经验一：Span 的合并优化非常重要，尤其在长列表场景下。一个大列表里如果每个 cell 都有 20 个 Span，内存占用会翻几倍，卡顿肉眼可见。

经验二：如果文本包含混合 emoji 和文字，建议先做 emoji 分段，再做样式拍平。不然 emoji 的字体回退逻辑可能覆盖相邻文字的样式。

4.4 ArkUI 侧渲染节点的生命周期管理

ArkUI 侧渲染节点的生命周期，分为创建、更新、销毁三个阶段。

创建阶段：拿到 RNTextNode 的数据，创建一个 ArkUI Text 组件，设置初始属性。这里要注意，Text 组件的创建是比较重的操作，不能频繁创建和销毁。所以我有几层优化：

• 组件复用：同一个 RNTextNode 多次渲染时，尽量复用 ArkUI 组件实例。
• 批量更新：RN 侧的 Props 更新是高频操作，ArkUI 组件不宜每次更新都全量 set，应该做 Diff。
• 数据懒加载：文本内容特别长时，可以采用分段懒加载，避免一次性生成海量 Span。

更新阶段：ArkUI 组件支持增量更新，比如 updateSpan、updateTextOverflow 等。RN 侧更新 Props 后，RNTextNode 需要计算“需要更新哪些参数”，生成一个最小更新集合，再调用 ArkUI 更新接口。这个 Diff 逻辑如果写好，性能提升非常明显。

销毁阶段：ArkUI 组件需要从组件树中移除，同时释放事件监听。事件监听释放特别重要，RN 侧的业务组件可能频繁挂载卸载，如果 ArkUI 侧事件监听没释放，会导致内存泄漏和数据错乱。

5. 工具选型与性能优化，实测数据说话

5.1 为什么最终选了这套实现方案

在做 Text 适配时，团队内部讨论过两套方案：

方案 A：直接使用 ArkUI 的 Text 组件，在属性层做映射。

方案 B：自己实现一个自定义渲染组件，完全绕过 ArkUI Text，直接用 Canvas 绘制文本。

方案 B 在性能上有吸引力，因为可以完全控制渲染逻辑，不受 ArkUI Text 的语义限制。但评估之后我们否决了，原因有三：

• Canvas 绘制文本，文本选择、无障碍、字体回退、emoji 渲染、复杂排版全都要自己实现，工作量不可控。
• Canvas 绘制和 ArkUI 的布局系统是割裂的，你需要在 Canvas 里模拟文本布局，但 Yoga 布局阶段只能拿到测量尺寸，后续的行内细节很难对齐。
• ArkUI Text 在 OpenHarmony 上已经做了大量底层优化，包括字体渲染缓存、排版引擎、native 层绘制，自己用 Canvas 重写很难超越。

所以最终选了方案 A：以 ArkUI Text 为基础，在适配层补齐 RN 语义。这个方案的核心优势是：渲染管线的收益是复用的，适配层只做语义转换，降低风险。

5.2 Text 组件渲染性能的三个瓶颈

在实际性能优化中，我遇到的主要瓶颈有三个：

第一，文本测量频繁调用。Yoga 在布局阶段会多次测量文本，如果测量函数每次创建离屏组件，性能会很差。我的优化方案是：增加测量缓存，以“文本内容+样式参数”为 key，缓存测量结果。实测下来，长列表场景的测量次数能降低 60% 以上。

第二，Span 节点过多。前面提到过，Span 合并是必须做的。我把 Span 合并逻辑做成了一个独立的工具类，支持对相邻同类 Span 做自动合并。实测一个典型业务页面，Span 数量从 400 个降到了 80 个，渲染耗时降低 30%。

第三，样式转换重复计算。Props 转换如果每次渲染都重新计算，会有大量重复工作。我做了两级缓存：第一级缓存每个 props 的转换结果，第二级缓存整个 Text 节点的样式快照。只有 props 真正变化时才重新计算。

这里补充一组我实测的数据：在一个包含 50 个文本节点的典型页面里，优化前 Text 组件的渲染耗时大约 50ms，优化后降到 15ms 左右；内存占用从 80MB 降到 45MB。对于手机端场景，这个提升感知还是很明显的。

5.3 长文本场景的专项优化

长文本是 Text 适配里一个特殊场景，很多问题在短文本上不容易暴露。比如：

• 长文本测量时，如果可用宽度很小，文本会被无限换行，测量时间会随着文本长度线性增长。
• 长文本生成 Span 时，如果文本中夹杂大量内层 Text，Span 数量和复杂度都会飙升。
• 长文本的截断策略，numberOfLines 和 ellipsizeMode 的组合逻辑，在不同字体、不同宽度下表现不稳定。

我的专项优化方案是：

1. 长文本测量降频：文本长度超过阈值（比如 500 字）时，采用分段测量，然后汇总结果。分段测量还有一个好处，可以更准确地处理换行和截断。
2. 截断计算前置：如果文本启用了 numberOfLines，在测量阶段就做一次截断模拟，拿到截断后的文本范围。这样渲染侧只需显示截断后的内容，不需要把完整长文本传给 ArkUI。
3. 文本缓存：相同文本、相同样式、相同宽度约束的测量结果，直接从缓存取，不重复测量。

这一套组合拳做下来，长文本页面的首帧渲染速度提升非常明显。

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

6.1 文本垂直偏移：fontsMetrics 和行高的纠葛

问题现象：一行文字在鸿蒙上显示时，总是比 iOS/Android 偏上或者偏下 2~3 个像素。

排查过程：我先检查了 fontSize 和 lineHeight 的映射，都正确。然后检查对齐方式，也正确。最后怀疑到字体度量上。HarmonyOS Sans 和 Roboto 的 ascent/descent 不同，导致基线位置不同。RN 的文本布局以基线为基准，而 ArkUI 的文本渲染可能以行框顶部为基准，两者叠加后就会出现垂直偏移。

解决方案：在测量层拿到字体度量的 ascent/descent，计算一个基线偏移量，在渲染时补偿到 y 坐标上。这个偏移量做成可配置项，不同字体族有不同的补偿值。

6.2 嵌套文本点击区域错位

问题现象：一个包含内层 Text 的富文本，点击内层 Text 的 onPress，有时候没反应，有时候点到了外层的事件。

排查过程：我打印了事件触发时的 target 信息，发现 ArkUI 的点击事件被绑定在最外层 Text 组件上，内层 Span 的点击事件无法准确区分。ArkUI 的 Span 不支持独立点击事件，这就意味着 RN 的嵌套 Text 事件需要自己实现命中测试。

解决方案：在适配层增加一个“文本命中检测”逻辑。点击事件触发后，根据点击坐标转换到文本内的相对位置，再遍历 Span 数组，判断该位置属于哪个 Span，然后只触发对应 Span 的事件。

这个方案做出来后，嵌套事件的命中准确率提升了非常多。但注意，这会有一定计算开销，所以只对包含事件响应的文本启用命中检测，普通文本不启用，避免性能损耗。

6.3 截断位置异常：ellipsizeMode 的组合逻辑

问题现象：文本设置了 numberOfLines=2，鸿蒙上第二行末尾的省略号位置和 iOS 不一致，有时候省略号出现在中间，有时候出现在末尾。

排查过程：RN 的 ellipsizeMode 支持 head/middle/tail，ArkUI 也支持这些模式，但两个平台的截断策略细节有差异。iOS 上 tail 模式默认在末尾截断，鸿蒙上如果在末尾截断时遇到标点符号，截断位置会提前，导致显示效果不一致。

解决方案：在渲染层不直接传 numberOfLines 给 ArkUI，而是自己实现截断逻辑：先测量完整文本的行数，如果超过限制，就按照指定的 ellipsizeMode 计算出截断文本，再交给 ArkUI 渲染。这样能保证跨平台行为一致，但会增加一次额外测量，所以也做了缓存。

6.4 性能排查：Text 组件突然卡顿

问题现象：一个页面里的 Text 组件数量不多，但滚动时突然掉帧。

排查过程：一开始我以为是渲染节点太多，后来发现是文本测量缓存失效过于频繁。有些 Text 的样式里包含随机值或者动态计算值，导致缓存 key 每次都变化，缓存形同虚设。定位到这个原因后，我调整了缓存策略：对于动态值，使用样式哈希作为 key 的一部分，同时增加内存上限，防止缓存无限增长。

还有一次卡顿是因为 Span 数组持有的是字符串的引用，长文本字符串没被回收，导致内存持续上涨。后来我把 Span 里的字符串改成不可变对象引用，并主动释放不再使用的 Span，才解决。

6.5 常见问题速查表

7. 关于这套方案还能怎么用

Text 组件的适配逻辑，不仅仅用于 OpenHarmony 的 RN 框架集成。它映射出的是一整套“跨端渲染语义对齐”的方法论。我把这套思路迁移到了其他组件上，比如 Image、View、ScrollView，发现核心思路是通用的：

• 先定义中间表示层，不直接映射。
• 再梳理语义差异，而不是属性差异。
• 然后做测量对齐，保证布局一致。
• 最后做事件和性能优化，提升体验。

如果你后续想扩展：可以在当前适配层上增加更多文本排版能力，比如支持富文本混排图片、支持自定义字体、支持竖排文本、支持文本无障碍朗读。这些方向，都可以沿用现有的中间表示层和 Span 生成逻辑，扩展性比直接改 ArkUI Text 好很多。

我个人在实际操作中的体会是：文本组件看似简单，实际上是一个集布局、排版、事件、性能于一体的综合体。做好它的跨端适配，不只是技术活，更需要对两个平台的渲染哲学有深入理解。如果你是在做鸿蒙适配，建议先把 Text 这个组件啃下来，它会暴露一大堆通用问题，帮你把适配框架的底子打牢。

最后再分享一个小技巧：调试文本布局问题时，可以开发一个“文本布局调试模式”，把每个文本组件的布局框、基线、行高、Span 边界都画出来。这个模式平时关闭，遇到问题再打开，问题定位效率会高非常多。

希望这篇文章能帮到正在做鸿蒙适配的你。有问题欢迎随时交流，我踩过的坑，你大概率也会遇到。