applymap 已被 Pandas 2.1.0 正式移除，应改用 df.map(func) 替代，它逐元素处理、跳过 NaN、性能更优，但要求列类型一致，且不支持上下文索引；非向量化场景才适用。
applymap 已被弃用，别再用了
从 Pandas 2.1.0 开始，applymap 方法正式被移除。如果你在新版本里调用它，会直接报错：AttributeError: 'DataFrame' object has no attribute 'applymap'。这不是拼写错误，也不是环境没装好——它就是没了。
替代方案是 map 方法，但它只作用于单个 Series；对整个 DataFrame 做逐单元格映射，得用 applymap 的精神继承者：map 不行，apply 太重，真正该用的是 apply 配合 axis=None？不，那是错觉——实际唯一可靠、等价且官方推荐的写法是：df.map(func)。
-
df.map(func)会遍历 DataFrame 中每个元素（跳过 NaN），对非空值调用func - 只适用于所有列都是相同可映射类型的场景（比如全是数值、全是字符串）
- 如果某列含混合类型（如
int和str混在同列），map会静默跳过无法处理的值，不报错但结果可能不符合预期 - 旧代码中
df.applymap(str.upper)要改成df.map(lambda x: str(x).upper())，注意先转str防止TypeError
df.map 为什么比 apply(axis=None) 更合适
apply 默认按列（axis=0）或按行（axis=1）工作，强行设 axis=None 并不能实现逐单元格处理——Pandas 根本不支持这个参数值，会直接抛出 ValueError: No axis named None。
有人试过 df.apply(lambda s: s.apply(func))，这确实能跑通，但它是双重循环：外层遍历列，内层遍历每列的值。性能差、语义绕、还容易在非均匀列上出错（比如一列是 datetime，一列是 bool，func 可能只适配其中一种）。
-
df.map(func)是 C 层优化过的逐元素操作，速度明显快于嵌套apply - 它自动跳过 NaN，行为和旧
applymap一致；而apply+apply默认不跳 NaN，需手动加na_action='ignore'（但这个参数只在Series.map里有效，DataFrame 没有） - 若函数依赖上下文（比如要知道当前行列索引），
map无能为力——这时候不该用逐单元格方案，该换思路，比如用stack()+apply+unstack()
常见报错和类型陷阱
最常遇到的是 TypeError: xxx is not callable 或 AttributeError: 'int' object has no attribute 'upper'。根本原因不是函数写错了，而是 DataFrame 里混了类型。
例如：df = pd.DataFrame({'a': [1, 'hello'], 'b': [3.14, True]})，此时 df.map(str.upper) 会在数字和布尔值上失败。
- 安全写法是统一兜底：
df.map(lambda x: getattr(x, 'upper', lambda: x)())？太绕。更实际的是先确认数据类型：df.dtypes，或用df.map(lambda x: str(x).upper() if isinstance(x, str) else x) - 数值列想转百分比字符串？别直接
df.map('{:.1%}'.format)，因为format对None报错。应写成：df.map(lambda x: '{:.1%}'.format(x) if pd.api.types.is_number(x) else x) - 涉及时间类型时，
pd.Timestamp支持.strftime()，但NaT不支持——map会跳过NaT，所以放心用；但自定义函数里若没判空，仍可能崩
什么情况下根本不该用 map
逐单元格处理本质是低效的——它放弃了向量化优势。只要函数逻辑能改写成 NumPy/Pandas 原生操作，就一定优先选那个。
- 把数字列全加 5？用
df + 5，别map(lambda x: x + 5) - 把字符串列全转大写？用
df.select_dtypes(include='object').apply(lambda s: s.str.upper())，比map更稳（因str.upper是向量化字符串方法） - 需要根据行列位置做不同处理（比如“第 0 行全乘 2，其余行不变”）？
map拿不到坐标，硬写只能用df.values+ 循环，但这时应该考虑np.where或布尔索引 - 函数本身很重（比如调外部 API、读文件）？逐单元格等于 N×M 次 IO，大概率卡死。必须重构：批量取数、一次请求、再按索引回填
真正需要 map 的场景其实很少：通常是清洗脏数据（统一转字符串、删特定字符）、或对接遗留函数接口。一旦发现写起来费劲、要不停 isinstance 判类型、或者性能明显变慢，就该停下来问一句：我是不是在用锤子拧螺丝？
