企业官网建设流程全解析

简介：面向数据分析与 Python 求职者的 Pandas 面试题整理，聚焦从基础概念到高级特性的系统复习，适合准备技术面试、需要快速梳理知识框架的初中级开发者查漏补缺。资源包含 1 个 PDF 文件，大小约 263KB，整体轻便，便于在电脑或移动设备上随时查阅。内容按基础、中级、高级及额外探讨分层组织，覆盖 Series 与 DataFrame、CSV 读写、条件筛选、排序合并、缺失值处理、分组聚合、时间序列、MultiIndex、pivot_table、rolling 窗口、内存优化与大数据分块处理等常见考点，并配有示例代码辅助理解。已有 1288 人学习，可用于面试前自测、知识点串联和实际编码时快速检索，帮助读者在较短时间内建立较完整的 Pandas 应答思路。

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

有个朋友第一次看别人做数据分析，盯着屏幕上一行行代码发愣：明明只是把一份销售表里“金额大于五百”的行挑出来，为什么要敲一串英文？我告诉他，那串英文背后站着一个叫 Pandas 的东西。你可以把它想成一张会自己算数的电子表格：在 Excel 里你靠鼠标点、靠拖拽填充，在 Pandas 里你把这些动作写成一句话，这句话能存下来、能改、能重复用一万次，还不怕手抖点错行。

Pandas 是 Python 里处理表格数据的核心库，它提供两种基本结构：一维的 Series 和二维的 DataFrame。前者的样子像一列数据，后者就是一张带行名和列名的表。搞懂它的关键不是背方法名，而是接受一个观念——表格本身是一个可以被整体操作的对象，而不只是一堆格子。

面试里频繁出现它，原因也在这里：会写几行代码的人很多，能说清“为什么这一步要这么写”的人少。一份题目从读取文件问到内存优化，考的其实是你脑子里有没有这张表的形状。

2. 为什么面试官盯着 Pandas 问：从数据结构说起

有位面试官讲过一个细节：候选人能顺口背出 merge 有 inner、left、right、outer 四种连接方式，可一问“如果右表里同一个键出现两次，合并后的行数会变成多少”，对方就卡住了。这不是记性问题，是脑子里没有那张表的形状。Pandas 的题目看着零散，其实都绕着同一件事转——你到底知不知道数据被摆成了什么样子。

2.1 Series 和 DataFrame：一列数据和一张表

Series 是“带标签的一维数组”。这句话里有三个关键词：一维、数组、标签。一维是说它只有一列；数组是说它底层是一段同类型的数据，算起来快；标签是说每个位置除了序号，还有一个你可以自己定的名字。DataFrame 则是把若干个 Series 并排放，共用同一套行标签，于是有了行和列两个方向。

下面这段代码把两种结构的最小形态摆出来，重点看取一列之后返回的到底是什么：

import pandas as pd # 用字典构造一张最小的表：键是列名，值是这一列的内容 df = pd.DataFrame({ "城市": ["甲市", "乙市", "丙市"], "销量": [120, 340, 90], }) # 取一列，得到的不是列表，而是 Series s = df["销量"] print(type(s)) # <class 'pandas.core.series.Series'> print(s.index.tolist()) # [0, 1, 2]，行标签默认是整数序号 print(s.values) # [120 340 90]，底层是一段同类型数组

这段代码的用意是打破一个常见误解：df["销量"]返回的不是 Python 列表，而是 Series，它仍然带着行标签。所以你可以继续对它做s.max()、s.sum()，也可以拿它和另一列做对齐运算。注意df[["销量"]]加了双层方括号，返回的才是 DataFrame——一列的表和一列的数据，差别就在这里。

DataFrame 还有一点和 NumPy 二维数组不同：每一列的数据类型可以不一样。城市列是文本，销量列是整数，这在一张表里完全正常。代价是当你跨列做数值计算时，Pandas 需要额外判断类型，这也是后面讲内存优化时绕不开的伏笔。

2.2 为什么是“带标签的表格”而不是二维数组

如果只是存数据，二维数组也能存。Pandas 非要多加一层行标签和列标签，是因为真实数据几乎从来不是整整齐齐来自同一个地方。订单表来自交易系统，客户表来自另一个系统，两边的顺序大概率对不上。靠位置去拼，错一行就全错；靠标签去拼，顺序乱了也能对上。

看一个刻意把顺序打乱的例子：

a = pd.Series([1, 2, 3], index=["甲", "乙", "丙"]) b = pd.Series([10, 20, 30], index=["丙", "甲", "乙"]) print(a + b) # 甲 21 # 乙 22 # 丙 13

两个 Series 的物理顺序是反的，但相加结果依然按标签对齐：甲的 1 配 b 里甲的 20。如果你把底层数组掏出来直接加a.values + b.values，得到的会是 11、22、33，看上去也挺整齐，实际上全错位了。

这就是“为什么”的答案：标签对齐不是花哨的附加功能，而是防止数据错位的一道保险。理解这一点，后面遇到索引重复、合并后行数变多、重置索引之后结果对不上，你都能顺着这条线索想明白，而不是把它当成玄学。

2.3 读进来、看一眼、写出去：数据流动的三个口子

绝大多数 Pandas 工作都从读文件开始，到写文件结束。中间那一大段清洗、筛选、聚合才是主体，但两头最容易翻车。翻车原因往往不是语法错，而是读进来的时候参数没设对，后面所有计算都建在歪掉的地基上。

# 读：把编码、列类型、需要的列一次性交代清楚 df = pd.read_csv( "orders.csv", encoding="utf-8", # 编码不对会读出乱码列名 dtype={"订单号": "string"}, # 订单号是编号，别让它被推断成数字 usecols=["订单号", "金额", "城市", "下单时间"], # 只读需要的列，省内存 parse_dates=["下单时间"], # 直接解析成时间类型，省一步转换 ) print(df.head(3)) # 看前三行：列名对不对、分隔符有没有读错 print(df.shape) # (行数, 列数) print(df.dtypes) # 每列被推断成了什么类型 # 写：index=False 表示不要把行号也写进文件 df.to_csv("clean.csv", index=False)

encoding是文件字符集，中文数据里最常见的坑就是读出乱码；dtype强制指定列类型，避免“001”这种编号被读成数字 1；usecols只加载需要的列，宽表能省下可观的内存；parse_dates在读入阶段就把字符串日期转成时间类型，省掉后面一次全表转换。写完文件时index=False也很关键，否则下次读回来会平白多一列没名字的行号。

输出方向不止 CSV。写到 Excel 用to_excel，写到 JSON 用to_json，反过来读网页表格用read_html，读数据库查询结果用read_sql。这些函数长得像，参数名却不完全通用，比如read_csv有sep，read_excel有sheet_name。面试里问“怎么把数据存成 Excel”，真正想听的是你知道 Excel 有多个工作表这回事，而不是只会背一个函数名。

2.4 缺失值：最容易被低估的一课

真实数据里空值是常态，不是意外。Pandas 用几种方式表示“这里没有值”：浮点列里是NaN，对象列里可能是None，较新的可空类型里是pd.NA。它们看着都是“空”，行为却有差别，比如NaN参与比较永远返回假，所以你不能用== np.nan去判断空值，只能用isna()。

还有一个容易被忽略的连锁反应：一个整数列里只要混进一个NaN，整列的类型就会被提升成浮点数。这不是缺陷，是 NumPy 数组必须同质的必然结果。知道这个原因，你就不会在看到“销量怎么变成 120.0 了”的时候一头雾水。

df = pd.DataFrame({ "门店": ["甲", "乙", "丙", "丁"], "销量": [120, None, 90, 150], }) print(df.isna().sum()) # 每列各有多少个缺失，先摸清底细再动手 print(df.dtypes) # 销量列已经从整数变成了浮点 # 只在销量为空时删掉整行，而不是整行有任何空就删 cleaned = df.dropna(subset=["销量"]) # 或者用中位数填充：比均值抗极端值 df["销量"] = df["销量"].fillna(df["销量"].median())

dropna的subset参数限定检查哪几列，how="all"表示整行全空才删，thresh则要求至少有 n 个非空值才保留。fillna除了给固定值，还能用前向填充ffill或后向填充bfill，这在时间序列里特别常用——但前提是你确认过“上一个有效值”确实能代表当前时刻，否则填进去的是假数据，比空着更危险。

3. 把表格当数据库用：筛选、合并、分组到底在做什么

很多人学 Pandas 的第一个错觉，是把它当成“Python 版的 Excel 操作”。用到后面才发现，它更像一个跑在内存里的小型数据库：有筛选条件、有多表关联、有分组聚合、有透视和重塑。这一章讲的四件事，基本覆盖了日常八成的数据处理动作。

3.1 条件筛选：布尔索引和 query 的分工

布尔索引的原理很朴素：先造一列真真假假，再用这列真假去“挑行”。df["金额"] > 500返回的是一个和原表等长的布尔 Series，把它塞进方括号里，为真的行留下。多条件时要用&、|、~，而且每个条件都得用括号包住，因为运算符优先级会让表达式悄悄变味。

# 布尔索引：多条件必须用 & | ~，每个条件都要加括号 mask = (df["金额"] > 500) & (df["城市"] == "甲市") sub = df[mask] # query：条件写成字符串，读起来更接近 SQL sub2 = df.query("金额 > 500 and 城市 == '甲市'")

用and和or会报错，原因是它们对整列做真值判断，而一列数据没有唯一的真假。这是新手最常见的踩坑点之一。query的好处是可读性，条件里有外部变量时用@变量名引用，比如df.query("金额 > @threshold")。

还有一个细节值得留意：布尔索引返回的是副本还是视图，取决于具体写法。连续用方括号取值再赋值，很容易触发警告甚至改不动原表。稳妥的做法是用.loc[行条件, 列名] = 值一次性完成定位和赋值，这也是面试里区分“用过”和“用明白”的一个小切口。

3.2 merge、join、concat：三种“拼表”不是一回事

三个函数都能把两份数据凑到一起，依据却完全不同。merge按列的值对齐，最像 SQL 的 join；join默认按索引对齐，写起来短；concat只是沿着某个方向把数据摞起来，不做匹配。分不清这三个，就会出现“明明合并了，行数却翻了三倍”这种事故现场。

orders = pd.DataFrame({"订单号": [1, 2, 3], "客户号": ["A", "B", "A"]}) clients = pd.DataFrame({"客户号": ["A", "B", "C"], "等级": ["金", "银", "铜"]}) # 左连接：以订单为准，每笔订单都保留，客户信息缺失就留空 df = pd.merge(orders, clients, on="客户号", how="left") print(len(df)) # 3 行，和左表一致

how参数决定保留谁：inner只留两边都有的键，left保左表全部，right反过来，outer两边都保。上面这段能保持 3 行，前提是右表的客户号唯一。如果右表里 A 出现了两次，左表那两笔 A 客户的订单就会各配两条等级记录，行数凭空变多。合并前先对键做一次唯一性检查，是省掉无数返工的血泪经验。

3.3 groupby 与聚合：分组之后到底发生了什么

groupby的动作可以拆成三步：按某个列的值把行分成若干堆，对每一堆算一个结果，再把结果拼回一张表。理解这三步，你就不会对它的返回类型感到意外——groupby之后拿到的不是表，而是一个还没算的中间对象，只有接上聚合函数才会出结果。

# 只对一列求和：返回 Series，索引是分组键 s = df.groupby("城市")["金额"].sum() # 命名聚合：返回 DataFrame，列名自己定，一次算多个指标 report = df.groupby("城市").agg( 总额=("金额", "sum"), 单数=("订单号", "count"), 均价=("金额", "mean"), )

命名聚合的写法值得记住，它把“结果列叫什么”这件事显式写了出来，比事后改列名清楚得多。count和size的区别也常被问到：count只数非空值，size连空值一起数，做单量统计时用错就会少算。

聚合函数除了内置的求和、均值、计数，还能传自定义函数，配合apply能做更复杂的计算。代价是灵活度和速度的交换：能用内置聚合解决的，就别急着上apply，后者本质上是逐组跑一遍 Python 函数，数据量一大差距会很明显。

3.4 透视表与 melt：宽表和长表之间来回

同一份数据有两种摆法。宽表把类别摊成列，一眼能横向比较；长表把类别压成一列，方便筛选和画图。pivot_table负责从长变宽并顺手聚合，melt负责从宽变长，stack和unstack则在列和索引之间搬来搬去。

wide = pd.DataFrame({ "门店": ["甲", "乙"], "一季度": [100, 80], "二季度": [130, 95], }) # 宽转长：把两个季度列压成“季度”和“金额”两列 long = wide.melt( id_vars="门店", # 保持不动的列 var_name="季度", # 原来的列名变成这一列的值 value_name="金额", # 原来的数值放进这一列 )

id_vars是不参与压缩的标识列，var_name和value_name决定新生成的两列叫什么。反过来用pivot_table时，index是行分组键，columns是摊开的列，values是填进去的数，aggfunc决定同一格有多条记录时怎么合并，默认是均值——这个默认值坑过不少人，做金额汇总时忘了写aggfunc="sum"，结果拿到一堆平均数还以为是原始数据。

4. 易混概念辨析：loc 与 iloc、apply 与 map 这些到底差在哪

Pandas 里有好几对函数，名字像、用法像、结果却不一样。面试里问它们，不是考记忆，而是考你有没有在这些相似的名字之间建立起清晰边界。下面五组是最容易混的，每组都按“混在哪、为什么混、怎么分”来说。

4.1 loc 和 iloc：一个看标签，一个看位置

易混点在于两者都写成df[...]的形式，都能取行取列，甚至都能切片。为什么混？因为默认索引是 0 到 n-1 的整数时，标签和位置恰好长得一模一样，用哪个都对，于是就懒得区分了。等到你把某列设成索引，两者立刻分道扬镳。

df = pd.DataFrame( {"姓名": ["A", "B", "C"], "分数": [88, 92, 75]}, index=["x", "y", "z"], ) print(df.loc["x":"y"]) # 按标签，两端都包含，取到 x 和 y print(df.iloc[0:2]) # 按位置，左闭右开，取到第 0、1 行 print(df.at["x", "分数"]) # 单个单元格，按标签，最快 print(df.iat[0, 1]) # 单个单元格，按位置

区分办法很简单：看方括号里写的是标签还是数字。写标签用loc，写位置用iloc，而且loc的切片包含右端点、iloc不包含，这个不对称是标准行为。只取一个格子时用at和iat，比loc和iloc快一截，因为省掉了对齐检查。

4.2 apply、map、applymap：作用对象不一样

易混点是名字都像“把某个东西用到数据上”。为什么混？因为日常说话里“应用”是一个词，落到代码里却要区分作用在元素、一列一行、还是整张表。区分的关键是看粒度和返回值：map作用在 Series 的每个元素上，apply作用在整列或整行上，applymap作用在 DataFrame 的每个元素上。

# map：逐元素替换，常用于把编码翻译成名称 df["城市名"] = df["城市码"].map({"01": "甲市", "02": "乙市"}) # apply：把一整列或一整行交给函数，函数拿到的是 Series df["分数档"] = df["分数"].apply(lambda v: "高" if v >= 90 else "低") # 逐元素处理整张表：不同版本里这个方法名字有过变化 df = df.apply(lambda col: col.astype("string"))

map专注逐元素映射，还能直接传一个字典做替换；apply更灵活，因为它拿到的是整列，可以结合多列信息做判断；逐元素处理整张表的方法在版本演进中调整过命名，写代码前先确认手头环境支持哪个，比照着旧教程硬抄稳妥。

4.3 merge 和 join：拼表的依据不同

易混点是两者都能把两张表合到一起。为什么混？因为在很多场景下，表的主键正好就是索引，两种写法结果一样，于是被当成同义词。真正的区别在依据：merge按你指定的列的值对齐，join默认按索引对齐。

区分办法是问一句“两张表靠什么对上”。如果对上的东西是一个普通列，用merge并把列名写进on；如果两边索引已经一致，join更省事。merge的参数更全，how、left_on、right_on、suffixes都能细调，复杂关联优先用它；join适合后续追加维护的简单场景。

4.4 pivot_table 和 crosstab：长得像，目的不同

易混点是两者都能生成一张行列交叉的表。为什么混？因为最简单的用法下，它们输出的形状几乎一样。区别在默认行为：pivot_table是聚合工具，values指定要汇总哪一列，aggfunc指定怎么汇总；crosstab是频次统计工具，不给数值列时算的就是“出现了多少次”。

分清楚的办法是看问题本身。问“每个城市每个月的销售总额”，这是聚合，用pivot_table；问“每个城市每个月的订单笔数分布”，本质是计数，crosstab写起来更直接。crosstab也能传values和aggfunc变成聚合，但那时它和pivot_table的区别就只剩写法风格了。

4.5 replace 和 where：一个换值，一个设条件

易混点是两者都在改单元格里的内容。为什么混？因为都涉及“原来的值不要了”。区别在判断依据：replace按值匹配，把等于某个值的全部换掉；where按条件判断，条件为真的保留原值，为假的替换成你给的值。

# replace：把“未知”这个字符串统一换成空值 df["城市"] = df["城市"].replace("未知", None) # where：金额小于 0 的异常记录，统一改成 0，其余保持不变 df["金额"] = df["金额"].where(df["金额"] >= 0, 0)

where的语义是“满足条件才留”，mask正好相反，是“满足条件就换”。这两个是同一件事的两种说法，记住一个另一个自然就通了。真正要小心的是：replace匹配的是完整值而不是子串，想按模式替换字符串得走字符串方法那条路。

5. 数据变大以后：内存、分块和时间序列怎么撑住

小数据上怎么写都对，数据一上来，写法之间的差距立刻显形。同样的清洗逻辑，有的写法几秒跑完，有的能把内存吃满然后被系统杀掉。这一章说的四件事，都是让代码在数据变大之后还能站住的关键。

5.1 dtype 与 Categorical：省内存不是玄学

一张表占多少内存，主要取决于两件事：有多少行，以及每列用什么类型存。整数从 64 位降到 32 位，内存直接减半；字符串列如果重复值很多，转成类别型之后只存一份字典加一串编号，压缩效果更明显。前提是你得先看清楚哪一列最占地方。

# deep=True 会真正统计字符串内容，不加这个参数估算会偏小 print(df.memory_usage(deep=True).sort_values(ascending=False).head()) # 低基数的字符串列（比如城市、渠道、状态）换成类别型 df["城市"] = df["城市"].astype("category") # 数值列降位要谨慎，先确认取值范围不会溢出 df["数量"] = df["数量"].astype("int32")

memory_usage的deep参数很关键，不加它只统计指针大小，字符串的真实占用会被严重低估。类别型适合“不同取值数量远小于行数”的列，如果一列几乎每行都不同，转成类别型反而更占内存，因为要额外维护字典。

数值降位则要看业务边界。把金额从 64 位降到 32 位确实省一半空间，但超过范围会溢出成错误的值，而且不会报错，只会悄悄算错。这种错误最难查，因为它不像语法错那样当场暴露。

5.2 chunksize 与大数据集：装不进内存怎么办

当文件大到一次性读不进来，最直接的办法是分块读：每次读一部分，算完丢掉，只保留累计结果。read_csv的chunksize参数就是干这个的，它返回一个可迭代对象，每次吐出一块 DataFrame。

total = 0 count = 0 # 每次读 10 万行，算完就释放，内存只跟单块大小有关 for chunk in pd.read_csv("big.csv", chunksize=100_000, usecols=["金额", "城市"]): total += chunk["金额"].sum() count += len(chunk) print(total, count)

这段写法能成立的前提是：你要的指标可以“分块累加”。求和、计数、最大最小值都属于这一类。排序、去重、需要看全量才能算的分位数，就没法简单分块，得换思路，比如先分块做局部去重再合并，或者干脆交给更适合的工具。

usecols和chunksize搭配使用效果最好，先把不需要的列砍掉，再把剩下的按块读，内存占用能压到很小。还有一个容易被忽视的点：分块读进来之后不要在循环里把每块都塞进一个列表存着，那样等于变相全量加载，前面的功夫全白费。

5.3 时间序列：resample、rolling 与时区

时间序列是 Pandas 最见功力的地方。字符串日期先转成时间类型，设成索引之后，按天、按周、按月汇总只要换一个频率字符串；滑动窗口用rolling算；涉及时区则要先本地化再转换，顺序反了会算错。

# errors="coerce" 会把解析失败的脏数据变成 NaT，而不是直接报错中断 df["下单时间"] = pd.to_datetime(df["下单时间"], errors="coerce") df = df.set_index("下单时间") # 按天重采样求和：没有数据的那天会出现，值可能是 0 也可能是空 daily = df["金额"].resample("D").sum() # 7 天滑动平均：前 6 天没有完整窗口，结果是空 week_avg = df["金额"].rolling(7).mean()

resample和groupby长得很像，区别是它专门按时间频率分组，D是天、W是周、M是月末。重采样之后缺失的时间点默认会产生空位，补 0 还是留空要看业务含义，订单金额补 0 合理，平均温度补 0 就荒唐了。

时区处理有个固定顺序：先tz_localize给一个没有时区的时间标上它属于哪个时区，再tz_convert换算到目标时区。直接把无时区时间当成本地时间参与计算，跨时区数据一合并就会出现几个小时的偏差，而这种偏差在汇总层面往往看不出来。

5.4 eval 与 query：什么时候真更快

Pandas 提供eval和query，号称用表达式做计算更快。快的原因是把整列运算交给底层引擎一次算完，避免 Python 层反复创建中间数组。但这个优势有前提：表要足够大、表达式要足够复杂，否则解析字符串的开销会把省下的时间吃回去。

# 一次算出新列，避免 df["金额"] - df["成本"] 产生临时数组 df = df.eval("毛利 = 金额 - 成本") # 同样支持多条件筛选，表达式里可以直接引用列名 sub = df.query("毛利 > 100 and 城市 == '甲市'")

在小表上，eval往往比直接写算式还慢一点。判断标准不是“用了就高级”，而是“这段计算是不是整列的大运算”。日常清洗里，可读性通常比那一点性能更值钱；只有在明确知道瓶颈在这一步时，再换写法才有意义。

6. 边界判断：什么时候该用 Pandas，什么时候别硬撑

Pandas 有一个很明确的舒适区：单机、内存放得下、以探索和清洗为主的分析工作。数据量在几百兆到几个 G 之间，它几乎是最顺手的选择——语法短、调试方便、画图导出一条龙。超出这个范围，它不会报错，只会越来越慢，最后在某一步莫名其妙地卡死或者被系统终止，让人以为是代码写错了。

真正该换工具的信号有这么几个。第一，文件大小远超可用内存，而且你需要做的操作没法分块累加，比如全量排序或者精确去重。第二，你需要多张表反复关联、还要并发写入，这时候数据库的索引和事务控制比内存里的表更合适。第三，同一份中间结果要被反复读取，那就别每次都从 CSV 重新解析，存成列式格式、只读需要的列，IO 会小很多。

上手之前先做个很便宜的判断，比事后救火省事得多：

import os # 先看文件多大，再决定要不要一次性读 size_gb = os.path.getsize("big.csv") / 1024 ** 3 print(f"文件约 {size_gb:.2f} GB") # 拿前一万行探路：列名、类型、缺失情况一次看清 sample = pd.read_csv( "big.csv", usecols=["订单号", "金额", "城市", "下单时间"], nrows=10_000, ) print(sample.dtypes) print(sample.isna().mean())

nrows只读前若干行，用来探路几乎不花时间；usecols提前砍列，宽表能省下大量内存；isna().mean()给出每列的空值比例，比看行数更直观。这三步走完，你基本能判断这份数据该直接在内存里处理，还是得分块。

我自己的习惯是：任何一份新数据到手，先跑一遍上面这三行，再决定后面怎么写。有次图省事直接read_csv读了一个几个 G 的文件，跑到一半进程被系统杀掉，前面的清洗逻辑一行没保存，只能重来。从那以后我每次拿到新文件都强制先看大小、先探前几千行，再动手写正式逻辑。这份 Pandas 面试题资料里从基础到高级的九十来道题，正好把这条从“会用”到“知道什么时候别用”的路铺了一遍，需要的话可以取来对着过一遍。希望帮到你。

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