给 AI 生成的移动端列表补上性能约束

让 ChatGPT 或 Claude 写一个 React Native 商品列表，通常不难；让它在中端 Android 手机上滚动 500 条数据时依然流畅，则需要更明确的要求。原文作者给出四项 FlatList 优化，以及一段可以直接复用的提示词。

这篇值得看的地方，是把「帮我优化性能」拆成了具体约束。但这些配置都有适用条件，作者也没有提供优化前后的对照数据，不能把提示词当成流畅度保证。

列表优化先管身份，再管重复渲染

作者首先要求给 FlatList 配置稳定的 keyExtractor，使用 (item) => item.id，避免用数组下标作为 key。

原因在于，key 决定 React 如何识别列表中的同一条记录。商品插入、删除或重新排序后，下标会变化，原来的位置可能换成另一件商品。除了带来不必要的更新，行内状态还可能对应到错误的数据。

稳定 key 首先解决的是数据身份问题。

第二项是给行组件加 React.memo，再用 useCallback 保持 renderItem 的函数引用稳定。作者给出的实现如下：

const ProductRow = React.memo(function ProductRow({ item }: { item: Product }) {
  return (
    <View style={styles.row}>
      <Text style={styles.title}>{item.title}</Text>
      <Text style={styles.price}>{item.price}</Text>
    </View>
  );
});

const renderItem = useCallback(
  ({ item }: { item: Product }) => <ProductRow item={item} />,
  []
);

要看清的是最后的依赖数组 []：这个示例没有读取会变化的外部值，所以可以这样写；业务组件若读取筛选条件、回调或其他状态，就必须重新检查依赖。

作者希望减少搜索框、计时器等触发父组件更新时的重复工作。不过，React.memo 能否跳过渲染，还取决于 props 是否保持稳定。如果每次都重新创建 item 对象，仅仅包上 memo 并不能达到预期。

固定行高和渲染窗口，都不能照抄

第三项是固定行高时使用 getItemLayout。原文设定 ROW_HEIGHT = 72，返回的布局信息中，length 为 ROW_HEIGHT，offset 为 ROW_HEIGHT * index，同时返回 index。

这相当于提前告诉列表：每一行有多高，第几行从哪个位置开始。列表可以减少测量，scrollToIndex 也能更准确地定位。

前提是行高真的固定。商品标题换行、图片尺寸变化或展开详情，都可能破坏这个假设。

第四项是减少首次渲染和视口附近保留的内容：

• initialNumToRender={10} 控制初始渲染数量。
• windowSize={5} 缩小渲染窗口；原文指出其默认值为 21，单位是屏幕高度，不是列表条数。
• removeClippedSubviews 用于裁剪屏幕外的子视图，但不应直接理解为所有屏幕外行都会卸载。

窗口缩小可以减少部分资源开销，也更容易在快速滚动时来不及填充，出现空白。作者因此要求在真机上测试。

下面这段提示词把四项要求和修改边界放在了一起，使用时把现有组件贴在后面：

Refactor this FlatList for performance:
- stable keyExtractor from item.id
- React.memo row component + useCallback renderItem
- getItemLayout (row height 72)
- initialNumToRender 10, windowSize 5
Don't add libraries. Keep my naming. Explain each change in one line.

要特别检查 getItemLayout (row height 72) 这一行。它是交给模型的业务前提，模型照着执行，并不代表这个前提正确。「不加库」「保留命名」「逐项解释」则让修改更容易审查，也能避免模型擅自替换列表方案。

我的判断

我认同作者把优化要求写具体的做法，但原文标题把卡顿归因于 AI，证据不够。作者描述了 500 条数据的场景，却没有提供设备型号、React Native 版本、测试过程或帧率对照。这更接近经验清单。

原文也简化了渲染机制：父组件更新不一定让所有可见行全部重渲染；行组件自己的状态或订阅的 context 变化，也不会被 React.memo 一概拦住。

测量方面，作者建议摇动设备打开 Perf Monitor，快速滚动时观察 JS 和 UI 帧率。JS 掉帧先检查行组件计算，UI 掉帧先检查图片和复杂样式，可以作为排查入口，但不能据此直接断定原因。

与更换列表库相比，先检查这些基础项，改动范围更容易控制；是否需要其他方案，仍要靠测量决定。文末的免费 10 条提示词 PDF，以及 118 页、50+ 提示词的付费指南属于推广内容。标注的 EARLYBF 优惠为 20%，截至 Nov 15，原文没有说明年份，不能据此判断现在是否有效。

能拿来做什么

• 让 AI 修改 React Native 列表前，先说明稳定 ID、真实行高和数据更新方式，不要直接沿用提示词中的 72。
• 审查 React.memo 和 useCallback 时，同时检查对象引用与依赖数组，避免只增加包装却没有减少工作。
• 把 initialNumToRender={10}、windowSize={5} 当作待验证的起点，在目标 Android 真机上检查首屏和快速滚动。
• 修改前后用相同数据、相同设备观察 JS 与 UI 帧率，并要求 AI 逐项解释改动，便于核对假设。