企业官网建设流程全解析

简介：这份Pandas面试题PDF面向数据分析、数据挖掘与后端开发岗位的求职者，也可供需要系统梳理Pandas知识体系的学习者查漏补缺。内容按基础、中级、高级三个层级组织，围绕六十个常见面试问题展开：基础部分涵盖Series与DataFrame、表格文件读写、列选择、条件筛选、排序合并、缺失值处理、分组聚合与索引重置；中级部分涉及函数应用与映射、时间序列、多级索引、数据拼接、分箱统计、数据类型转换及字符串处理；高级部分延伸到内存占用优化、大文件分块读取、类别型数据、数据库交互、自定义聚合、透视表与窗口函数，并配有简明代码示例辅助理解。资源包共一个PDF文件，大小约二百六十三KB，轻量便于在电脑或手机上随时翻阅。目前已有1288人学习或下载，适合需要对照高频考点系统复习、补充实战思路并在面试前快速检索的读者。

1. 到底什么是 Pandas：一张会算数的电子表格

很多人第一次听到 Pandas，会联想到那个圆滚滚的黑白动物。在数据分析圈里，Pandas 是一个 Python 库的名字，你可以先把它当成一张会算数的电子表格：打开是行列分明的格子，但每一列都能一次性做筛选、排序、分组、合并，几十万行也不用手动拖公式。差别在于，表格软件靠鼠标点，Pandas 靠几行代码把「我要哪几列、按什么条件、怎么汇总」说清楚。搞懂它不只是为了应付面试，而是因为招聘方默认你会用它把一堆脏数据整理成能看的样子。这份题库把常见问法按基础、中级、高级排了序，往下读之前，先弄明白它到底在解决什么问题。

2. 为什么面试官盯着 Pandas 问：从 Series 和 DataFrame 说起

数据分析岗的面试里，Pandas 出现的频率高得有点反常。原因不复杂：它卡在「原始数据」和「能给人看的结果」之间，是绝大多数分析流程里真正干活的那一层。数据库负责存，画图库负责展示，中间清洗、对齐、汇总、重塑的活，八成落在 Pandas 身上。面试官问它，本质上是在判断你有没有亲手把一份乱糟糟的表整理干净过。

这一章先把两个地基概念讲清楚：一维的 Series 和二维的 DataFrame，再解释为什么几乎所有题库都从读取文件开始问，最后拆开这份题库的分层逻辑。

2.1 一维的 Series 和二维的 DataFrame 到底差在哪

通俗地说，Series 是一列带编号的清单，DataFrame 是一整张带行号、带列名的表。你从 DataFrame 里取出一列，得到的就是一个 Series；你把几个长度相同、编号相同的 Series 并排放，就得到一张 DataFrame。这个关系听起来像废话，但它决定了很多操作的默认行为。

关键在于「编号」这两个字。Pandas 的每一行都有一个索引（index），它可以是从 0 开始的数字，也可以是日期、城市名、订单号。这个索引不是装饰，它参与运算。两个 Series 相加时，Pandas 不是把第一个的第一个数和第二个的第一个数相加，而是先按标签对齐，标签对不上的位置直接补缺失值。

import pandas as pd s1 = pd.Series([1, 2, 3], index=["a", "b", "c"]) s2 = pd.Series([10, 20, 30], index=["b", "c", "d"]) # 按索引标签对齐后再相加，对不上的位置补 NaN print(s1 + s2) # a NaN # b 12.0 # c 23.0 # d NaN

这段代码里，index参数决定了每个值挂在哪个标签下。相加时先做标签匹配：b和c两边都有，正常相加；a只在左边有，d只在右边有，结果就是缺失值。如果换成两个纯数字列表相加，得到的是位置对齐的结果，行为完全不同。

提示：理解「按标签对齐」这件事，后面 merge、join、concat 的各种默认行为都能顺下来。它是 Pandas 区别于普通二维数组的根本设计。

DataFrame 则可以看成「共享同一个行索引的一组 Series」。这个定义解释了两件事：一是为什么给 DataFrame 加一列那么方便，直接赋值一个 Series 就行，索引会自动对上；二是为什么索引乱了之后各种操作都开始出问题，因为所有列的对齐都依赖它。

2.2 为什么几乎所有数据分析岗都从 read_csv 开始问

真实工作里，拿到数据的第一步不是分析，是把它弄进来。一份 CSV 看着简单，实际能踩的坑不少：分隔符不是逗号、表头缺失、编码不对导致中文变乱码、数字列被读成了字符串、日期列读进来是一串文本。面试官从读取问起，是在确认你有没有处理过「不干净的输入」。

read_csv的参数很多，但真正高频的就那几个。下面这段是一个相对完整的读法：

import pandas as pd df = pd.read_csv( "orders.csv", sep=",", # 分隔符，制表符文件改成 "\t" usecols=["order_id", "city", "amount", "created_at"], # 只读需要的列 dtype={"order_id": "string", "amount": "float32"}, # 显式指定类型 parse_dates=["created_at"], # 直接解析成日期类型 na_values=["", "NULL", "-"], # 统一识别缺失值写法 encoding="utf-8", # 编码不对时先试 utf-8 再试 gbk )

参数逐个说：sep决定怎么切分字段；usecols是省内存最直接的一招，读进来再删列已经晚了，内存已经花出去了；dtype显式指定类型，避免整数列因为混进一个空值就整列变成浮点，也避免 ID 列被当成数字后丢掉前导零；parse_dates让日期列一步到位，省掉后面反复转换；na_values把各种奇怪的缺失写法统一成标准缺失值；encoding是中文数据最常见的翻车点，读出来一堆问号或乱码，十有八九是这里没对上。

题库里还专门有一条问非 ASCII 字符怎么处理，问的其实是同一件事的另一面：数据里带中文、带特殊符号时，读入、比较、导出三个环节都可能出问题，编码要前后一致。

2.3 90 道题背后的三层认知：基础、中级、高级

文件的标题写的是 60 个面试题，打开会发现编号一路排到了 90，多出来的那部分更像延伸讨论。不管数量怎么算，它的分层方式很典型，值得单独说一下，因为这套分层几乎就是「会用 → 用得顺 → 用得省」的三级台阶。

基础那一档围绕四件事打转：把数据搬进来、看一眼长什么样、把需要的行列挑出来、把两张表拼起来。具体包括基本数据结构、读取 CSV、查看前几行、选列、条件筛选、排序、merge、设置索引、处理缺失值、增删列、重置索引、导出、遍历行、描述性统计、groupby、字符串转日期、重命名、透视表、唯一值计数。这些操作的共同点是「单步可完成」，知道方法名就能写出来。

中级那一档开始出现组合动作：把函数应用到列或行、多条件筛选、时间序列处理、多级索引、join、空值查找与替换、map 与 apply 的分工、cut 与 qcut 的分箱、多个表的纵向横向拼接、类型转换、正则匹配、频次统计、直接画图、宽长表转换、导出 Excel、读取网页表格、字符串拆分成多列、显示行列数设置、取最大最小的前 n 行、查看数据类型。这一档考的是「知道什么时候该用哪个」，同一件事往往有三四种写法，选错不报错，但结果不对或者慢得离谱。

高级那一档转向工程性：优化内存占用、处理装不进内存的大数据集、用 Categorical 提升性能、与数据库交互、时间区间与周期、自定义聚合函数、用多级索引表达高维数据、pivot_table 与 crosstab 的区别、窗口函数做复杂聚合、整体性能优化、缺失时间点的补齐、分层采样、文本处理、标准化归一化、多条时间序列的对齐、多数据源合并、模拟 SQL 的分区计算、数据清洗流程、groupby 之后的复合运算。到了这一档，问的已经不是「你会不会」，而是「你有没有在真实数据量下被教育过」。

额外那部分则明显偏向「和别的工具对标」：排名、样式美化、条件赋值、导出 JSON、pivot 与 melt 的重塑、索引的增删、日期算术、缺失日期、按日期分组、去重、类 Excel 的透视、query 查询、at 与 iat 单值访问、stack 与 unstack、股票数据、多个聚合函数并用、replace 与 where 的差别、两个表的差异比对。这些题目单看很碎，放在一起其实是同一个问题：Pandas 能不能替代你熟悉的那些表格操作和 SQL 写法。

3. 四类高频操作：筛选、合并、分组、重塑是怎么运转的

如果只记零散的方法名，用起来会很吃力。Pandas 的日常操作其实可以归到四类动作上：从表里挑出想要的部分、把几张表拼成一张、按某个维度汇总、把表的形状改成需要的样子。这四类动作覆盖了题库里绝大部分题目，也覆盖了真实工作里绝大部分时间。

3.1 筛选：把想要的行和列挑出来

最直白的写法是布尔索引，把一个真假序列塞进方括号里：

# 布尔索引：条件为真的行留下 filtered = df[df["amount"] > 100] # 多条件要用 & 和 |，每个条件外面必须加括号 filtered = df[(df["amount"] > 100) & (df["city"] == "北京")] # query 写法更接近自然语言，列名里有空格时用反引号包起来 filtered = df.query("amount > 100 and city == '北京'")

这里有个新手常翻车的地方：多个条件不能用and、or连接，要用&、|，而且每个条件必须用括号括起来。原因是运算符优先级，不加括号时 Python 会先算比较再算位运算，结果和你想的完全不一样，而且不报错。

按位置和按标签取数则是另一组工具。loc按行标签和列名取，iloc按从 0 开始的位置取，at和iat是它们的单值版本，取一个格子时更快。这四个选择器的分工值得单独记牢，第 5 章会展开讲它们最容易混的地方。

3.2 合并：三套拼表工具的分工

拼表是题库里出现频率很高的一类题，因为有三种看起来都能拼、实际行为差别很大的方法。

merge是 SQL 风格的连接，按某一列或多列的值匹配，how参数决定保留哪边的行：inner只留两边都有的，left保留左表全部，right保留右表全部，outer两边都保留。join默认按索引匹配，写法更短，适合索引本身就是键的场景。concat不做匹配，直接把多个表沿某个方向堆起来，axis=0是纵向摞行，axis=1是横向并列。

这张表里最值得记住的是join的默认值和merge不同：merge默认inner，join默认left，写的时候不显式指定，很容易在数据缺失时得到意外结果。另一个细节是重复键：两边的键不唯一时，匹配会产生笛卡尔积式的膨胀，行数突然翻好几倍，这类问题在真实数据里非常常见。

3.3 分组与聚合：拆分、应用、合并三步

groupby 的运作方式可以概括成三步：按某个键把表拆成若干小块，对每块做一次计算，再把结果合并回一张表。理解这三步，就能理解为什么 groupby 后面能接的东西那么多。

# 按城市分组，一次算多个指标 result = ( df.groupby("city") .agg( order_cnt=("order_id", "count"), # 命名聚合，结果列直接叫 order_cnt amount_sum=("amount", "sum"), amount_avg=("amount", "mean"), ) .reset_index() )

这段用了命名聚合语法，agg里每个参数写成「新列名 = (源列名, 函数名)」的形式，出来的结果列名清晰，不用事后重命名。如果不关心列名，也可以直接传一个函数列表，但结果会是多级列名，后面取用麻烦。

除了agg，还有一个常被忽略的transform：它同样按组计算，但返回的结果和原表行数一致，会把每组的计算结果广播回原来的每一行。想做「每个城市的均值」和「每行金额占本城市均值的比例」，用transform一步到位，用agg还得再 merge 回去。

题库里还有一道问 groupby 之后怎么做复合运算，比如先求和再求平均。这类需求的写法是把聚合结果当成新表继续算，或者用pipe把多步串起来。真正需要注意的不是语法，而是想清楚「平均的是原始行，还是分组后的汇总值」，这两者算出来完全不同。

3.4 重塑：宽表和长表之间的来回转换

同一份数据可以横着摆，也可以竖着摆。宽表是一行一个对象、每种指标占一列；长表是一行一个观测、用一列存指标名、一列存指标值。画图、分组、建模通常喜欢长表，人看报表通常喜欢宽表，所以这两种形状之间的转换非常高频。

melt是宽转长：指定要保留的标识列，其余列被压成「变量名 + 变量值」两列。pivot和pivot_table是长转宽：前者要求每组只有一个值，遇到重复就报错；后者自带聚合函数，遇到重复会按指定方式合并。stack和unstack则是在索引层级上做升降维，把列旋到行、把行旋到列，适合处理多级索引。

pivot_table和crosstab经常被放在一起问。通俗地说，前者是「给原始明细表做透视」，指定值列和聚合方式；后者更像「数频次」，默认统计组合出现的次数，适合做交叉计数表。两者都能出二维汇总，但输入和默认行为不一样，混着用虽然也能出结果，但会绕远路。

4. 性能那一档：内存、类型和分块处理为什么常被追问

前面那些操作，学会方法名就能写。真正拉开差距的是另一类问题：数据量一大，代码还是那几行，跑起来却卡死或者直接报内存不足。题库里高级部分有接近一半的题目绕不开这个话题，原因很实在——面试官想知道你有没有被真实数据量教育过。

4.1 一份 CSV 为什么能吃掉好几倍内存

很多人有个直觉：文件多大，读进内存就多大。实际差得远。一个 200MB 的 CSV，读成 DataFrame 之后占 1GB 内存是常有的事。

原因在类型推断。Pandas 读文件时会猜每列的类型，猜不出来就统一当成对象类型，也就是字符串。而字符串在内存里存的不是字符本身，是一个指向实际内容的指针，每个指针加上对象头开销，比原始文本大好几倍。整数列如果混进一个空值，整列会从整数变成浮点，内存直接翻倍。日期列如果没指定解析，就是一堆字符串。

查看真实占用要用memory_usage(deep=True)，不加deep参数只统计指针大小，看不出字符串的真实开销：

# deep=True 才会把字符串的实际内容算进去 print(df.memory_usage(deep=True)) print(df.dtypes) # 先看类型，object 列通常是内存大户

这两行输出放在一起看，基本能定位问题：哪一列是 object，哪一列占的比例异常高，改哪一列收益最大。

4.2 Categorical 与 dtype 缩小的取舍

如果某一列的取值种类很少，比如性别、省份、订单状态，把它转成 Categorical 类型能省下大量内存，还能加快分组。原理是把每个不重复的值只存一份，其他位置存指向它的编号。

# 低基数列转成类别型，内存能降一个数量级 df["city"] = df["city"].astype("category") # 数值列按实际范围降级，int64 到 int8 不会丢信息的前提下省 7 倍 df["count"] = pd.to_numeric(df["count"], downcast="integer") df["amount"] = pd.to_numeric(df["amount"], downcast="float")

astype("category")适合取值种类远小于行数的列，几十种以内效果明显；如果一列几乎每行都不同，比如订单号，转成类别型反而更占内存。downcast的思路是看实际数值范围，能塞进更小的类型就塞，但要注意边界：负数、超大值、精度要求高的金额列不能随意降级，否则会出现静默的精度损失。

注意：Categorical 列不能直接做所有数值运算，排序默认按类别顺序而不是字面顺序。转换之前先确认这一列后面要参与什么计算。

4.3 chunksize 与 eval：装不下时的两条退路

数据真的装不进内存时，最实用的办法是分块读。read_csv的chunksize参数让每次只读一部分，处理完就丢掉，内存里始终只有一块。

# 分块读取，每块算完只保留聚合结果 total = 0 for chunk in pd.read_csv("big.csv", chunksize=100_000): total += chunk["amount"].sum() # 每块处理完即释放 print(total)

这段的chunksize=100_000表示每次读 10 万行，返回一个可迭代对象，每次循环拿到一个 DataFrame。适合求和、计数这类可以分批累加的任务；如果是需要全表排序或全表去重，分块就无能为力了，得换思路。

另一条路是减少中间对象。Pandas 的eval和query底层会把表达式交给更底层的计算引擎，避免为每个中间步骤都创建一张临时表。像df["a"] + df["b"] * df["c"]这种多步运算，写法上省不了几个字符，但在大表上省下的内存是实打实的。

题库里还有一条专门问「DataFrame 很大无法直接加载进内存怎么办」，标准答案通常就是三件事：先想清楚能不能只读需要的列，再用分块，最后考虑换工具。前两步能解决大部分场景，第三步属于另一个话题。

5. 常见误区与易混概念：这五个坑一混就露怯

有些概念单看都懂，放在一起就糊。面试里最能暴露功底的，往往不是会不会用某个函数，而是能不能说清两个相似方法的分界。下面这五组是题库里反复出现、日常使用中也最容易混的。

5.1 loc 和 iloc：按名字还是按位置

易混点：两个都带方括号，都接受行、列两个参数，写出来长得几乎一样，结果却可能完全不同。

为什么混：名字只差一个字母，而且很多示例里 DataFrame 的索引恰好是 0、1、2、3，这时候df.loc[0]和df.iloc[0]拿到同一条数据，看不出区别。一旦索引被设成日期或字符串，两者立刻分道扬镳。

怎么区分：loc看的是标签，方括号里写的是索引里真实存在的值，切片时包含右端点；iloc看的是位置，写的是从 0 开始的整数序号，切片时不包含右端点。判断方法很简单：如果你心里想的是「第几行」，用iloc；如果想的是「索引等于什么的那一行」，用loc。顺带一提，at和iat是这两个的单值版本，取单个格子时更快，但同样遵循标签和位置的区分。

5.2 merge 和 join：都是拼表，默认行为完全不同

易混点：两个方法都能把两张表按某个键拼起来，参数里也都有how，看起来是同一个东西的两种写法。

为什么混：在键唯一、两边都齐全的情况下，两者结果一模一样，日常小数据里几乎碰不到差异。差异要等到数据有缺失或者索引不规整时才暴露。

怎么区分：merge按列的值匹配，默认inner，只保留两边都匹配上的行；join按索引匹配，默认left，保留左表全部。如果没显式写how，用merge会觉得数据莫名变少，用join会觉得数据莫名变多出一堆缺失值。稳妥的写法人人都懂，但真正做到每次都写清楚how和on，得靠习惯。

5.3 pivot_table 和 crosstab：透视和计数长得太像

易混点：两者都能产出一张二维的交叉表，行一个维度、列一个维度，中间是数值，肉眼看不出区别。

为什么混：当pivot_table的聚合函数用count时，结果和crosstab几乎一致。很多人因此以为它们是同一功能的不同名字。

怎么区分：pivot_table的输入是明细表，你要指定哪个列做值、用什么函数聚合，默认是求平均；crosstab的输入通常是两列原始数据，它直接数这两个维度组合出现的次数，默认是计数。想做「每个城市每类商品的销售额」，用pivot_table；想做「每个城市每类商品有多少条记录」，用crosstab更直接。用错了也能出数，但代码读起来别扭，还容易在参数上绕圈。

5.4 map 和 apply：一个按元素，一个按整行整列

易混点：两者都能把一个函数套到数据上，写出来都是「传个函数进去」，很多时候结果也一样。

为什么混：传进去的函数只处理单个值时，apply的行为和map确实接近，看不出差别。差别在函数需要看到整行或整列时才显现。

怎么区分：map是 Series 的方法，逐个元素替换或转换，函数收到的是一个值，返回一个值，它不能访问同一行的其他列。apply更通用，作用在列上时收到一整列，作用在行上时收到一整行（一个 Series），所以能写「根据这行的单价和数量算出金额」这类跨列逻辑。判断标准是：函数需不需要别的列，需要就用apply，不需要就用map，后者通常更快。

5.5 replace 和 where：一个换值，一个按条件留值

易混点：两者都能改变表中的值，都能达到「某些位置变成另一个值」的效果。

为什么混：用where配合取反条件，能拼出和replace一样的结果，所以很多人觉得它们可以互换。

怎么区分：replace是「把 A 换成 B」，按值匹配，跟条件无关；where是「条件为真的位置保留原值，为假的位置替换成指定值」，按条件判断。想改某个具体取值，用replace；想按一列或多列的条件批量处理，用where或它的反向版本mask（mask是条件为真时替换）。两者还有个容易忽略的差别：where默认不修改原表，需要显式赋值或者传inplace，忘了接返回值就会觉得「怎么没生效」。

6. 什么时候该翻这份题库，什么时候别翻

这份资料真正的价值不在「背答案」，而在「按图索骥地查漏」。下面这张表可以帮你判断自己该不该花时间在它上面。

判断标准其实只有一条：你有没有一张真实的、脏的表要处理。有的话，对着题库里的问题去表上试一遍，印象会比读十遍答案都深；没有的话，光看题目和代码，过两天就忘干净。

还有一个容易被忽略的边界：题库里的答案大多是「标准写法」，而真实数据里同一件事往往有好几种写法，性能差好几倍。比如逐行遍历 DataFrame，语法上完全正确，几万行也跑得动，但换成向量化写法可能快几十倍。题库里有一道专门问怎么迭代遍历行，正确的态度是知道有这么个写法，同时知道它通常不是首选。

我自己在这件事上翻过车。早年处理一份几百万行的日志表，图省事写了个iterrows循环，本地小样本跑得挺顺，上了全量数据直接卡住，等了半天以为程序挂了。后来改成按列向量化运算，同样的逻辑几秒钟出结果。从那以后我每次写循环之前都强制问自己一遍：这个操作能不能整列一起算？能不能用groupby或where替掉？问完再动手，省下的调试时间远比多想那几秒值钱。

所以这份题库最合适的用法，是把它当成一张检查清单：先挑几道自己有把握的，确认手感还在；再挑几道看着眼生的，当场在编辑器里试；最后把试不出来或者结果和预期不一致的记下来，那些才是你真正要补的地方。希望帮到你。

本文还有配套的精品资源，点击获取