at比loc快的本质是绕过标签解析和视图构造：它直接通过哈希表定位(row_label, col_name)内存地址，跳过loc所需的参数解析、索引检查、返回对象构建及Copy-on-Write等全部通用逻辑。
at比loc快的本质：绕过标签解析和视图构造
因为at是专为「单标量 + 标签索引」设计的底层直写接口，它跳过了loc里所有通用逻辑：不校验切片合法性、不处理布尔索引、不构建中间Series或DataFrame视图，甚至不触发Copy-on-Write检查（除非启用了新引擎）。实测在百万行DataFrame中随机取10万次单点值，at平均耗时约0.8s，而loc常达2.5s以上。
哪些操作会让loc变慢，而at完全不走这些路径？
loc必须做这些事：
• 解析传入的行/列参数是否为列表、切片、布尔数组或标量
• 检查索引是否有序，决定用哈希查找还是二分查找
• 构造返回对象的类型（Series、DataFrame或标量）
• 触发__getitem__完整链路，含_maybe_update_cacher等开销at只做一件事：用哈希表直接定位(row_label, col_name)对应内存地址，读/写一个Python对象。
用错at反而更慢甚至报错的典型场景
• 传入不存在的行标签或列名 → 立即抛KeyError，而loc可能静默扩展DataFrame
• 用df.at[df['x'] > 5, 'y'] → 报TypeError: cannot do label indexing on ，因为at根本不接受布尔序列
• 在循环中反复调用at但未预设索引 → 若索引是未排序字符串，每次哈希查找仍需O(1)均摊，但不如先set_index再用at稳定
• 修改含category或nullable integer类型的列时，若赋值类型不匹配，at会静默转类型或报ValueError，而loc有时会宽容转换
真正想提速？别只换at，先看数据结构
单纯把loc[i, 'col']换成at[i, 'col']能提2–5倍速，但如果你要批量改满足条件的单元格：
• 别用循环+at → 即使快，仍是O(n)逐个查
• 改用df.loc[df['a'] > 5, 'b'] = 0 → 底层走矢量化布尔索引+内存块拷贝，快一个数量级
• 如果查询列固定且高频，先df = df.set_index('id').sort_index() → 后续at查找从平均O(1)变成稳定O(1)，且避免哈希冲突抖动
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
