---
url: /articles/2.11-release.md
---
# Mpx 2.11.0 版本正式发布，跨端样式能力增强，对 AI coding 更加友好 {#mpx-2-11-release}

> 作者：hiyuki

在 Mpx 2.11.0 中，我们围绕跨端输出 RN 做了一轮中型版本升级。本次升级的主线在于：让 Mpx2RN 的样式能力更接近 Web / 小程序开发者熟悉的 W3C 语义，让 `class`、`wx:class`、`style`、`wx:style` 等不同样式入口具备一致能力，同时继续降低 RN 运行时高频渲染路径的成本。

对于正在将小程序项目输出到 RN 的团队来说，这意味着更少的平台差异、更少的条件编译，以及更稳定的复杂页面渲染性能。

## 跨端样式能力拉齐 W3C 标准 {#rn-style-standard-alignment}

RN 原生样式体系和 Web / 小程序之间存在较大天然差异，Mpx2RN 过去通过编译与运行时结合的方式对齐进行了系统性抹平，但是在文本继承、盒模型默认值和 CSS 简写属性等细节能力上仍存在差异，2.11.0 对这些差异进行了查缺补漏进一步抹平，使其更加符合 W3C 标准。

### 文本样式继承

首先是文本样式继承。RN 原生要求文本内容必须落在 `Text` 节点中，很多文本样式也只能直接作用在 `Text` 上；而 Web / 小程序中更常见的写法，是在 `view` 这类容器节点上统一声明 `color`、`font-size`、`line-height`、`text-align` 等文本表现，再由内部文本自然继承。这个差异过去会直接暴露给跨端适配：同一块 UI 在小程序中只需要切换容器状态，在 RN 侧却可能需要额外找到每个内部文本节点并补齐样式。

2.11.0 中，Mpx2RN 可以将容器节点上的文本样式透传到 Mpx 子树中的 `text` 节点，即使中间存在非 text 组件也不会中断；父级 `text` 的文本样式也可以继续传递给嵌套的子 `text`。这让“在容器上描述文本表现”的写法更加接近 Web / 小程序心智，尤其适合卡片选中态、主题色切换、禁用态、深浅色模式、局部字号缩放等场景。

| 有文本样式继承 | 无文本样式继承 |
| --- | --- |
| ![有文本样式继承时，AI 跨端适配能够正确处理内部文字选中态高亮](https://dpubstatic.udache.com/static/dpubimg/ibU61iu65XyqzFs2GSXEi.png) | ![没有文本样式继承时，AI 未能正确处理内部文字选中态高亮](https://dpubstatic.udache.com/static/dpubimg/eYUif85LfrJsOUHz30J3-.png) |
| 选中态只需要作用在外层卡片，内部“4分钟 / 预计车辆到站 / 一中公交站”等文本可以继承高亮色，AI 迁移时更容易保留原始设计语义。 | AI 只处理了容器背景色，内部文本仍保持默认深色，视觉上没有形成正确的选中态高亮。 |

这个能力带来的收益不只是少写几行样式。对于复杂业务组件来说，文本节点往往分散在多层组件、条件渲染和插槽结构里，选中态的文字颜色、字号、行高如果不能从容器继承，就需要在模板、样式和脚本之间反复传递状态。人手改造容易遗漏某个分支，AI 改造则更容易只修到当前可见节点，忽略隐藏态、异步数据或组件内部文本。文本样式继承把这类跨端差异收敛到框架运行时，业务代码可以继续表达“这张卡片被选中，所以卡片内文字进入高亮态”，而不需要把这个意图拆成多个 RN 专属细节。

当然，文本样式继承也有明确边界。Mpx2RN 继承的是文本相关样式，包括 `color`、`font*`、`text*`、`letterSpacing`、`lineHeight`、`includeFontPadding`、`writingDirection` 等；布局、盒模型、背景、边框等非文本样式不会被当作文本样式继承。`numberOfLines`、`ellipsizeMode` 属于文本截断能力，不会作为普通文本样式继续向更深层文本传递。如果某个容器的文本样式或文本截断属性只会在后续动态数据中出现，需要在首次渲染时显式声明 `enable-text-pass-through`。

```html
<!-- 首次渲染时 selected 可能为 false，容器上还没有 color；
     后续切换选中态时，需要提前声明 enable-text-pass-through。 -->
<view
  class="station-card"
  enable-text-pass-through
  wx:style="{{
    selected
      ? { color: '#fff', background: '#ff5a35' }
      : { background: '#f0f4fa' }
  }}"
>
  <text class="eta">4分钟</text>
  <text class="desc">预计车辆到站</text>
  <view class="station-wrapper">
    <text class="station">一中公交站</text>
  </view>
</view>
```

如果容器在首次渲染时已经通过 class 或 style 带有文本样式，通常不需要额外配置；`enable-text-pass-through` 主要用于上面这种“初始无文本样式，后续动态出现文本样式或文本截断属性”的场景。

### 默认盒模型拉齐

其次是默认盒模型，RN 原生默认 `box-sizing` 使用 `border-box`，而非 Web / 小程序默认的 `content-box`。2.11.0 中 Mpx2RN 默认将业务节点盒模型对齐到 `content-box`，同时提供了 `rnConfig.defaultBoxSizing` 配置，存量业务需要快速升级时仍可按需切回 `border-box`。这能显著减少固定宽高、padding、border 同时存在时的跨端布局偏差。

```js
import mpx from '@mpxjs/core'
// 正常不建议开启该配置
mpx.config.rnConfig.defaultBoxSizing = 'border-box'
```

### 样式简写能力增强

最后是简写属性能力增强，本次重点补齐和强化的 CSS 简写属性如下：

| 属性 | 支持形式 | 处理说明 |
| --- | --- | --- |
| `gap` | `gap: <row-gap> <column-gap>?` | 展开为 `rowGap` / `columnGap`；单值同时作用于行列，百分比在运行时按容器尺寸换算。 |
| `inset` | `inset: <top> <right>? <bottom>? <left>?` | 按 CSS 四值规则展开为 `top` / `right` / `bottom` / `left`。 |
| `border`、`border-top`、`border-right`、`border-bottom`、`border-left` | `<width>`、`<style>`、`<color>` 顺序不敏感 | 按值类型展开到对应 `border*Width`、`borderStyle`、`borderColor`；缺省宽度按 `medium = 3px` 补齐，缺省样式按 `none` 处理。 |
| `outline` | `<width>`、`<style>`、`<color>` 顺序不敏感 | 展开为 `outlineWidth` / `outlineStyle` / `outlineColor`；缺省规则与 `border` 对齐，`outline-style: none` 会在运行时转换为 `outlineWidth: 0`，最终表现依赖 RN 版本的 `outline` 能力。 |
| `font` | `[font-style] [small-caps] [font-weight] <font-size> [/ <line-height>] <font-family>` | 展开为 `fontStyle`、`fontVariant`、`fontWeight`、`fontSize`、`lineHeight`、`fontFamily`；`font-size` 与 `font-family` 必填，不支持的可选 token 会被忽略并告警。 |
| `text-decoration` | `none` / `underline` / `line-through`，可组合 `solid` / `double` / `dotted` / `dashed` 与颜色 | 展开为 `textDecorationLine` / `textDecorationStyle` / `textDecorationColor`；`underline line-through` 会合并为同一个 `textDecorationLine`，`style` / `color` 表现受 RN 平台能力约束。 |
| `text-shadow` | `<offset-x> <offset-y>? <blur-radius>? <color>?` | 展开为 `textShadowOffset` / `textShadowRadius` / `textShadowColor`；缺少 `offset-y` 时按 `0` 补齐，颜色缺省为 `#000`。 |
| `background` | `url()` / `linear-gradient()` / 颜色 / `no-repeat` / `none`，并支持 `<position> / <size>` | 展开为 `backgroundImage`、`backgroundColor`、`backgroundRepeat`、`backgroundPosition`、`backgroundSize`；`background-size` 支持 `contain`、`cover`、`auto` 和长度值，不支持多重背景。 |

部分无序简写会按 CSS 规范根据值类型解析，例如 `border: red solid 1px` 与 `border: 1px solid red` 都能得到正确结果。`background` 也进一步支持 `background-position / background-size` 语法。

```css
.card {
  gap: 24rpx 16rpx;
  inset: 0 24rpx;
  border: #e5e5e5 solid 1px;
  outline: red solid 1px;
  font: italic bold 28rpx / 1.5 Arial;
  text-decoration: underline dotted #1677ff;
  text-shadow: 0 2rpx 4rpx rgba(0, 0, 0, 0.2);
  background: url("https://example.com/bg.png") no-repeat center / cover #fff;
}
```

## 运行时样式增强 {#runtime-style-enhancement}

2.11.0 的另一个重点，是补齐运行时样式入口的处理能力，让 `style` / `wx:style` 和编译期 `class` / `wx:class` 样式能力实现平权。

过去一些样式增强主要发生在 `<style>` / class 编译阶段，而通过 `style`、`wx:style` 等动态入口进入的样式，可能无法获得同等处理。现在 Mpx2RN 在运行时补齐了 CSS var / UnoCSS var 解析、简写展开、`flex` / `background` / `transform` / `font` 样式转换等同编译期一致的样式处理能力。

这意味着：

* `class` / `wx:class` 中可用的样式简写属性，`flex` / `background` / `transform` / `font` 等需要 Mpx 转换处理的样式，现在在 `style` / `wx:style` 中同样可用。
* CSS var 和 fallback 中同样可使用上述简写属性和特定样式，不再受限。

对开发者来说，这一点非常关键：动态样式不再是“弱一等”的入口。很多原本需要拆成长属性、绕开 CSS 变量或写条件分支的场景，现在可以保持更自然的 CSS 写法。

```html
<view
  class="card"
  wx:style="{{
    {
      margin: '16rpx 24rpx',
      border: active ? '2rpx solid #1677ff' : '0',
      background: `var(--card-bg, #fff)`
    }
  }}"
/>
```

## 对 AI 生成与迁移代码更友好 {#ai-friendly-development}

Mpx2RN 样式能力的增强，也是在提升框架对 AI 编程的友好度。

在跨端输出 RN 的旧适配模式中，很多 Web / 小程序中自然成立的写法，在 RN 侧并不原生支持。例如容器上的文本样式继承、CSS var 中使用简写属性、`style` 中动态写入 `border` / `background` / `font` 等简写，都可能需要被拆成多处等效实现：模板里补 `text` 或迁移属性，样式里拆成长属性，脚本里配合动态 class / style，必要时还要加条件编译。这样的改造往往不是单文件修改，而是模板、样式、脚本甚至组件调用方之间的协同调整。

对人来说，这类改造已经很容易遗漏边界；对 AI 来说，风险会更高。AI 可能只看到了某个样式属性不兼容，于是局部替换成 RN 写法，却没有同步处理原平台表现、动态样式入口、CSS 变量 fallback、文本子树继承关系或组件默认样式优先级。最终结果可能是“看起来改了”，但实际影响面难以评估。

2.11.0 通过框架层统一抹平这些差异，让 AI 更容易生成正确代码，也更容易安全地改造旧项目：

* 容器文本样式继承由运行时统一处理，AI 不需要为了 RN 单独重排文本节点结构。
* 简写属性在 `class`、`wx:class`、`style`、`wx:style` 等入口中的能力更一致，AI 不需要根据入口差异拆成不同写法。
* 默认盒模型、文本缩放、简写展开和组件默认样式优先级都有稳定规则，AI 更少依赖隐性平台知识。
* 跨端差异收敛到框架内部后，代码审查时也更容易判断一次 AI 改动的真实影响面。

换句话说，本次升级不只是让手写代码更接近标准 CSS 心智，也让 AI 生成、迁移和重构 Mpx2RN 代码时拥有更稳定的目标语义。

下面是一组 AI 迁移同一小程序页面到 Mpx2RN 的效果对比。可以看到，旧版框架中更容易出现文本样式丢失和层级样式不一致的问题；升级到 2.11.0 后，适配结果与源平台效果更加接近，文字颜色、字号和整体视觉层次的偏差明显降低。

| 微信小程序效果 | Mpx2RN skill 适配效果（旧版框架 2.10.21） | Mpx2RN skill 适配效果（新版框架 2.11.0） |
| --- | --- | --- |
| ![微信小程序源页面效果](https://dpubstatic.udache.com/static/dpubimg/Tv0d1sMr56iaG_n15n32v.png) | ![Mpx2RN skill 在旧版框架 2.10.21 中的适配效果，存在较明显的文字样式丢失](https://dpubstatic.udache.com/static/dpubimg/EmHp6XaPYGpIuS8Ep7XSW.png) | ![Mpx2RN skill 在新版框架 2.11.0 中的适配效果，文字样式和源平台更加接近](https://dpubstatic.udache.com/static/dpubimg/sCKdmUd3Hub25HmbDq0UQ.png) |

适配 2.11.0 的新版 skills 已经同步发布，详情查看当前仓库内：.agents/skills/mpx2rn

## RN 运行时性能优化 {#rn-runtime-performance}

在样式能力增强的同时，我们也对 RN 运行时热路径做了一轮性能优化，重点覆盖 `view`、`text`、`simple-view`、`simple-text`、`image`、`useTransformStyle`、`background` 等高频链路。

本轮优化主要围绕几类通用手段展开：在样式处理前先判断是否真正命中特殊能力，避免普通节点进入完整增强流程；在拆分 style / props 时尽量复用原对象引用，减少临时对象分配；在背景、图片等高频能力上延迟或跳过不必要的解析、状态更新和回调绑定；同时压缩组件默认逻辑中的无效分支，让列表、卡片这类重复节点在批量渲染和全量更新时少做无关工作。

我们构造了一个接近业务真实压力的商品网格页面 DEMO 做了对比验证：页面包含 500 张商品卡片，单轮渲染约 1000 个 view、1000 个 text，500 张卡片均使用了本地背景图。测试场景为 Android 设备 20 轮采样，对比“背景图 + 全量更新”下从触发页面更新到 `$nextTick` 的总耗时。

| 版本 | `JS 初始化 -> onReady` 平均耗时 | `全量更新 -> nextTick` 平均耗时 | 说明 |
| --- | --- | --- | --- |
| 原版本 | 8135ms | 6004ms | 样式增强优化前 |
| 优化版本 | 7917ms | 3989ms | 样式增强优化后 |

> 平均值按报告口径剔除最高 2 个与最低 2 个样本后计算。优化版本为快的那组数据，原版本为慢的那组数据。

可以看到，首屏 `onReady` 的总耗时变化不大，主要收益集中在全量更新链路：`全量更新 -> nextTick` 从 6004ms 降到 3989ms，更新总耗时下降约 **33.6%**。这也符合本轮优化的预期：首屏初始化受 JS 初始化、页面创建、资源加载等因素共同影响，而全量更新会集中放大 view / text / background / props / innerProps 等运行时热路径差异。

进一步看 `@mpxjs/perf` 的框架内置探针，优化收益更加清晰。全量更新 window 中，原版本 `view:render` avg 为 1.422ms，优化版本为 0.894ms，原版本相对优化版本慢 **59.0%**；`view:render:createElement` 慢 **80.4%**，`view:render:props` 慢 **137.5%**，`text:render:style` 慢 **71.9%**。这说明优化收益并不主要来自 `getStyle` 本身，而是来自 render 链路上的 props 拆分、innerProps 处理、文本样式处理、background 子节点构造等高频成本下降。

| 指标 | 优化版本 avg | 原版本 avg | 原版本相对优化版本 |
| --- | --- | --- | --- |
| `view:render` | 0.894ms | 1.422ms | +59.0% |
| `view:render:style` | 0.344ms | 0.423ms | +22.8% |
| `view:render:createElement` | 0.482ms | 0.869ms | +80.4% |
| `view:render:props` | 0.022ms | 0.053ms | +137.5% |
| `text:render:style` | 0.070ms | 0.121ms | +71.9% |

峰值数据也印证了这一点。在全量更新场景下，原版本 `view:render` max 可达到 69.83ms，优化版本为 13.67ms；原版本 `text:render` max 为 26.27ms，优化版本为 2.59ms。也就是说，本轮优化不仅降低了平均耗时，也明显压低了复杂样式更新下的长尾尖峰。

对于大列表、复杂卡片、带背景图或渐变的页面，这类优化会更明显地体现在滚动、全量刷新和批量状态更新等交互场景中。

此外，本版本继续完善了 `@mpxjs/perf` 运行时测速探针，作为框架内部性能分析与业务定位问题的辅助工具。它不是本次升级的使用重点，但为后续持续优化 RN 运行时热路径提供了更贴近 Mpx 抽象层的数据来源。

## 实现原理 {#implementation-principle}

作为 2.11.0 新增支持的核心能力，本章会结合示例介绍文本样式继承的实现原理，性能考量，以及其是如何与运行时样式能力增强结合工作的。

文本样式继承并不是简单地把父级 `style` 原样塞给子级 `text`。它依赖一条更完整的运行时样式处理链路：先把来自 `class`、`wx:class`、`style`、`wx:style` 等入口的样式，经过 CSS var 解析、`calc()` 处理、样式简写处理和单位换算等步骤，规整成稳定的 RN style，再从中拆出真正可继承的文本样式，最后通过上下文传递给文本子树。运行时样式增强负责前半段的标准化，文本样式继承负责后半段的上下文传递和最终合并，两者配合后才能让“在容器上描述文本表现”的写法在 RN 侧继续成立。

下面以一个具体父子结构为例：顶层 `view` 声明 `color` 与 `font` 简写，中间 `view` 只有布局样式，底部两个 `text` 分别声明 `font-size` / `line-height` 和 `font` 简写。运行时会在每一层按需处理样式，并让最终表现尽量贴近 W3C 中“父级文本样式可被文本后代继承、子级自身样式后合并覆盖”的心智。

![Mpx2RN 父子文本样式继承与运行时性能优化流程](https://dpubstatic.udache.com/static/dpubimg/5xH2dnbGWbFwKJpUgAb_A_2.11-runtime-style-text-inheritance.png)

首先，顶层 `view` 的样式会进入 `useTransformStyle`。这一层处理的是运行时样式增强：如果样式来自 `style` / `wx:style`，其中的 `font`、`background`、`border`、`gap`、CSS var、`calc()`、百分比等写法会和 class 编译产物一样被标准化处理。以示例中的 `font: 600 24rpx / 150% Arial` 为例，运行时会按需展开为 `fontWeight`、`fontSize`、`lineHeight`、`fontFamily` 等 RN 可识别字段；如果这些值来自 CSS var 或动态表达式，也会先完成变量解析、百分比 / `calc()` 处理和必要的单位转换。

样式标准化之后，`splitStyle` 会把结果拆成三类：布局、盒模型、背景等普通样式继续留给当前 `View`；`backgroundImage`、`backgroundSize`、`backgroundPosition` 等背景样式交给 `mpx-view` 的背景子节点处理；`color`、`font*`、`text*`、`lineHeight` 等文本相关字段则被拆成 `textStyle`。这一步是文本继承的边界：只有文本表现会进入继承链路，布局、背景、边框等非文本样式不会被错误传递给后代 `Text`。

拆出的 `textStyle` 会交给 `useTextPassThrough`，与父级文本上下文合并后写入 `TextPassThroughContext`，再由 `wrapChildren` 包裹子树。这里有一个关键细节：父级的 `lineHeight: '150%'` 不会在顶层 `view` 上提前算成固定数字，而是继续以百分比中间态向下传递。因为真正应该决定行高基准的是最终 `text` 节点合并后的 `fontSize`，而不是某个祖先容器的字号。

再看中间 `view`。它只有 `padding` 这类布局样式，没有 `color`、`font*`、`text*`、`lineHeight` 等文本样式。此时运行时不会创建新的文本上下文或 Provider，已有的 `TextPassThroughContext` 会通过 React Context 自然穿过这一层。因为这一层没有需要参与文本继承的内容，运行时可以继续走普通布局样式路径：无文本特殊 key 时尽量复用原对象，也不做额外上下文合并和子树包裹，减少高频渲染中的对象分配和 React 节点开销。

最后到两个底层 `text`。`text A` 自己声明了 `font-size: 20rpx` 和 `line-height: 120%`，运行时会先拿到父级继承的 `color`、`fontWeight`、`fontFamily` 等，再用自身样式后合并覆盖；因此它最终保留父级颜色和字体族，但字号变为自身的 `20`，行高按自身字号计算为 `20 * 120% = 24`。`text B` 则通过 `font: 700 30rpx / 1.2 Arial` 声明自身文本表现，`font` 简写同样先经过运行时样式增强展开，其中 unit-less 的 `1.2` 会先保留为 `120%`，等最终 `fontSize: 30` 确定后再计算出 `lineHeight: 36`。

这套顺序本质上是在 RN 上模拟更接近 CSS 继承与级联的行为：运行时样式增强先把动态样式和简写语义规整到统一形态，父级可继承文本样式再进入上下文，子级自身样式后合并并覆盖，百分比 `font-size` / `line-height` 延迟到最终文本节点再解析。这样既能让“在容器上描述文本表现”的写法继续成立，又能避免混排文本中大字号片段被祖先层提前算出的较小行高压缩。

性能上，这条链路也尽量只在必要时工作。`useTransformStyle` 会先收集 key 特征，再进入 CSS var、`calc()`、百分比、简写展开、背景解析等对应分支，普通样式不会无差别跑完整增强流程；组件默认样式会在用户样式转换完成后再兜底写入，避免用户简写被默认长属性反向覆盖；`splitStyle` / `splitProps` 在没有特殊 key 时尽量复用原对象；文本上下文内容只有发生变化时才替换引用，减少子树无意义更新。对于“首屏没有文本样式、后续动态出现文本样式或截断属性”的节点，则需要提前声明 `enable-text-pass-through`，用稳定的启用状态保障 Hook 执行顺序及子树结构稳定。

## 更多值得关注的能力增强 {#more-highlights}

除上述主线外，2.11.0 还包含一些对 RN 输出和跨端一致性很有价值的能力点：

* RN 模板支持无值布尔属性，例如 `<scroll-view scroll-y />` 会按微信语义等价为 `true`。
* `image`、`video` 及自定义内建组件支持本地静态资源路径，`image` 新增 `is-svg` 属性用于强制 SVG 渲染。
* 新增 RN `section-list` 扩展组件，支持自定义列表头尾、分组头尾、分组吸顶、下拉刷新、手势协同以及 `scrollToIndex()`。
* `picker` 补齐 `range`、`range-key` 动态更新和触发区域文本样式透传能力。
* `createSelectorQuery().select()` / `selectAll()` 支持查询非 `virtualHost` 自定义组件的实体 host 节点。
* 新增 `rnConfig.disablePageTransition` 配置，用于统一关闭 RN 页面转场动画。
* 组件默认样式与用户简写样式的优先级问题得到修复，例如用户写 `border: 0`、`margin: 0`、`flex-flow: column nowrap` 时，不再被组件内部默认长属性反向覆盖。
* `createIntersectionObserver().observe()` 支持传入 refs，并修复多个 `nodeRefs` 场景下的目标解析问题。
* `text-decoration-style` / `text-decoration-color` 会按 iOS、Android 与 Harmony 的实际支持范围进行校验和转换。
* 修复 Android 输入框 `confirm-type` 与触摸交互、相机权限重复请求、安全区顶部初始化、页面级导航栏文字样式，以及 `picker-view-column` 项高度和滚轮动画等问题。
* RN 内建组件过滤小程序属性，避免无效属性直接透传给 RN 原生组件。
* 自定义组件和 built-in 组件的 `displayName` 传递更完整，调试体验更好。
* Web 输出优化 UnoCSS 注入顺序，拉齐小程序中 UnoCSS 覆盖全局样式的行为。
* Web 模板处理增强，支持 `<import>` 与 `<template>` 场景下的模板转译复用。
* RN 环境 API 修复 BLE 连接相关回调管理问题，补齐无效 callback 检查，优化 `offBluetoothAdapterStateChange`、`offBLEConnectionStateChange` 等监听移除语义，并修复鸿蒙默认写入方式。
* `@mpxjs/api-proxy` 补全位置、系统、键盘和相机相关 API 的 TypeScript 类型定义。
* i18n 修复了字面量 key 与路径解析、`NaN` 归一化相关问题。
* URL query 解析修复逗号被误拆分的问题。

## 升级指南 {#upgrade-guide}

Mpx 2.11.0 是一次以跨端样式能力增强为核心的体验升级。它从样式标准拉齐、样式能力补充和运行时样式一致性三个层面显著增强跨端输出 RN 的样式解析能力，并通过精细的运行时热路径优化保障性能，同时提升对人和对 AI 的跨端开发友好度。

对于全新项目，我们推荐直接升级到 2.11.0。新版本可以默认享受更完整的文本样式继承、运行时样式增强、CSS 简写支持、默认盒模型对齐和 RN 运行时性能优化，也能让后续 AI 生成、迁移和重构代码时拥有更稳定的目标语义。

对于存量项目，升级前需要重点关注样式表现回归。由于 2.11.0 的样式能力支持程度与之前版本存在较大差异，一些过去在 RN 侧未生效、被拆解处理或依赖平台差异的样式，升级后可能会按照更接近 Web / 小程序的语义生效。因此建议在升级后对核心页面、复杂组件、动态样式、文本混排、选中态、禁用态、盒模型尺寸等场景进行全量视觉回归，确认最终表现符合预期。