at(-1)更安全，因它语义明确表达“取最后一个”，避免length-1手动计算导致的越界风险和逻辑掩盖；空数组时同样返回undefined，但行为标准化、支持负索引、TypeScript类型推导准确，且性能优于slice(-1)[0]。
为什么 at(-1) 比 arr[arr.length - 1] 更安全
当列表为空时，arr[arr.length - 1] 返回 undefined，看似无害，但容易掩盖逻辑错误——比如你本以为列表非空，结果后续操作基于这个 undefined 报错，堆栈里却找不到源头。而 at(-1) 行为一致（也返回 undefined），但语义更清晰：它明确表达“我要最后一个”，不是“我手动算索引再取”。更重要的是，它天然支持负索引语法，无需条件判断或兜底计算。
常见误用场景：
- 在
useEffect依赖数组里写list[list.length - 1]?.id，一旦list异步清空，可能触发意料外的副作用 - 服务端返回空数组，前端仍用
items[items.length - 1].name解构，直接Cannot read property 'name' of undefined
at() 在 TypeScript 中需要补什么类型声明
原生 Array.prototype.at 在较老版本 TypeScript（如 4.5 以下）中不可见，编译会报 Property 'at' does not exist on type 'any[]'。不建议强行 // @ts-ignore，应升级到 TypeScript 4.6+，或手动补充接口声明：
interface Array<T> {
at(index: number): T | undefined;
}注意两点：
- 不要覆盖整个
Array接口，只扩展缺失方法，避免破坏原有类型推导 - 如果项目还在用
@types/node旧版，需确认其未屏蔽全局Array的at声明（某些 v16.x 版本有冲突） - 返回类型是
T | undefined，不是T，别漏掉可选链或空值检查
和 slice(-1)[0] 对比：性能与可读性取舍
slice(-1)[0] 是旧写法里最接近 at(-1) 的替代，但它会创建新数组，哪怕只取一个元素。在高频渲染或大数据列表中（比如每秒更新 60 次的实时日志流），这种临时数组分配会增加 GC 压力。
实测（Chrome 120，10 万元素数组）：
-
arr.at(-1)：平均耗时 ~0.002ms -
arr.slice(-1)[0]：平均耗时 ~0.08ms（40 倍开销） -
arr[arr.length - 1]：平均耗时 ~0.001ms（最快，但语义弱、易出错）
所以优先级应该是：at(-1) > arr[arr.length - 1] > slice(-1)[0]。只有当你必须兼容 IE 或 Node.js
动态列表更新时，at(-1) 会不会引发 React 重渲染异常
不会。React 渲染是否触发，取决于你如何把 at(-1) 的结果用于 JSX 或依赖数组，而不是 at 本身。但容易踩的坑是：
- 在
useMemo里写list.at(-1)?.id，而list是引用变化的数组（比如每次 API 返回新数组），那即使末尾元素没变，useMemo也会重新计算——这不是at的问题，是依赖项粒度太粗 - 用
at(-1)取值后直接塞进useState初始化，比如const [last, setLast] = useState(list.at(-1))，这只会取初始值，后续list更新不会同步 —— 和用list[0]一样，属于使用时机误解
真正要留意的，是负索引在 SSR 场景下是否被服务端 runtime 支持（Node.js ≥ 16.6 没问题；若用 Vercel Edge Functions 或 Cloudflare Workers，需查对应运行时版本）。
