原文：Index as a key is an anti-pattern
我曾多次看到开发者在衬着列表的时刻把列表项的index作为它的key。
{todos.map((todo, index) =>
<Todo {...todo}
key={index} />
)}
这看起来很文雅，而且可以处置惩罚正告（这才是“真”题目，对吧？）的题目，如许做有什么风险呢？
It may break your application and display wrong data!
让我来诠释，key是React唯一用来肯定DOM元素的东西，假如你想列表增添一项或移除中心的某项，会发作什么事？假如key和之前一个一样React就会假定这个DOM元素和之前对应的组件是一个，然则它们能够并非同一个了。
为了证实潜伏的风险我建立了一个简朴示例
这表明，假如不指定key的时刻React会运用index，由于这是那个时刻最好的猜想，而且它会正告你说这不是最优解(它经由过程令人困惑的语句表述这个意义)。假如你主动供应了它，React就以为你晓得你在干什么。记着这个示例，它能发生不可展望的效果。
比较好
像如许的应当都有一个永远的唯一的属性，当列表项建立的时刻它是最合适被设置为key的，明显我是在说id，我们可以用下面的体式格局运用它：
{todos.map((todo) =>
<Todo {...todo}
key={todo.id} />
)}
别的的完成体式格局是把编号递增移动到笼统要领中，运用一个全局的index来确保任何两个列表项的id差别。
todoCounter = 1;
function createNewTodo(text) {
return {
completed: false,
id: todoCounter++,
text
}
}
更好
一个产物级别的计划应当是一个更硬朗的要领，可以处置惩罚疏散建立列表项。因而，我引荐运用shortid。它可以疾速天生“短 无序 url友爱 唯一”的id，代码像下面如许：
var shortid = require('shortid');
function createNewTodo(text) {
return {
completed: false,
id: shortid.generate(),
text
}
}
TL;DR:为每一个列表项天生一个唯一的id，并在衬着列表的时刻运用它作为key。
