ReactJS如何动态设置数组子元素的唯一key属性？附Mongoose疑问

我太懂这种困扰了——React的key警告说起来简单，但真碰到Mongoose数据的时候，有时候会摸不清到底该用啥当key。先给你拆解下项目里的常规做法，顺便解答你关于加key字段的疑问：

1. 优先用Mongoose自带的_id（最常用） #

这绝对是项目里最省心的方案！Mongoose给每个文档自动生成的_id是全局唯一的ObjectId，完全符合React对key的要求——唯一且稳定。你根本不用额外做任何操作，渲染的时候直接拿它当key就行：

// 假设你从数据库拿到的users数组是Mongoose文档数组
const UserList = ({ users }) => {
  return (
    <ul>
      {users.map(user => (
        <li key={user._id}>{user.name}</li>
      ))}
    </ul>
  );
};

这个方法几乎没有维护成本，也是社区公认的最佳实践之一，除非你有特殊理由不能用_id，否则直接用它就对了。

2. 用业务场景下的唯一字段 #

如果因为某些原因不想用_id（比如觉得ObjectId太长、不想在前端暴露等），可以找你Schema里本身就保证唯一的业务字段——比如用户的email、商品的sku、文章的slug这类字段，只要你在Schema里给它们加了unique: true约束，就可以放心拿来当key：

// 比如你的User Schema里已经设置了email唯一
const UserSchema = new mongoose.Schema({
  name: String,
  email: { type: String, unique: true, required: true }
});

// 渲染时用email当key
const UserList = ({ users }) => {
  return (
    <ul>
      {users.map(user => (
        <li key={user.email}>{user.name}</li>
      ))}
    </ul>
  );
};

这种方式的好处是key更语义化，但前提是这些字段真的能保证全局唯一，不然还是会触发React的警告。

3. 关于给Schema加key字段：不是不良实践，但没必要 #

你说的给每个Schema对象加key字段，其实不算“坏实践”，但属于冗余操作——毕竟Mongoose已经给你生成了_id这个天然的唯一标识，额外加key字段等于多维护一个需要保证唯一性的字段，还要在创建文档的时候手动生成（比如用uuid库），平白增加了工作量。

除非你有非常特殊的需求（比如需要更短的key、或者业务上要求用自定义标识），否则完全没必要这么做。

避坑提醒：别用数组索引当key #

很多人一开始会下意识用map的索引当key，但这是个大坑！如果你的数据会发生增删、排序变化，索引作为key会导致React的虚拟DOM比对出错，引发渲染异常，绝对要避免这种写法：

// 错误示例！别这么做
users.map((user, index) => <li key={index}>{user.name}</li>)

总结下来，项目里的优先级是：_id > 业务唯一字段 > 自定义key字段，按照这个顺序选就不会错啦。

内容的提问来源于stack exchange，提问作者ANUBIS