做 Web 和自动化相关开发的同学，迟早都会碰到一个看起来简单但藏了不少坑的需求：把一张图片从 Python 代码里变成一长串文本，然后再把这串文本塞进 JSON、写进数据库、拼到接口返回值里，或者直接扔给前端渲染。这里面的关键组合就是 Python、PIL 和 Base64 字符串。这篇内容要做的就是把这套“图片转字符串、字符串转图片”的完整链路给你讲透，包括怎么用 Pillow 处理图片、怎么用 Base64 编码、你写的时候会撞上哪些典型的坑，以及最后怎么在真实项目里落地。不管你是刚接触 Python 的小白，还是已经写过几年业务代码但很少碰图像处理的开发者，这篇文章都能让你拿过去直接“抄作业”。
先说一下我自己的使用场景。前两年做内部系统时，经常需要把各种临时生成的验证码、订单截图、图表预览图从前端传到后端，或者从后端返回到前端。有同事图省事直接把图片以文件路径传来传去，结果部署到不同服务器之后路径全乱，图片全挂。后来我把方案统一成“PIL 生成图片 → Base64 字符串 → 接口传输”，虽然数据体积变大了一点，但跨平台、跨服务、跨进程传递全都顺了。今天就把这个过程中积累的经验完整分享出来。
1. 为什么要把图片变成Base64字符串：场景与原理
1.1 哪些现实场景需要图片转Base64
很多人第一反应是：我直接把图片文件传过去不就好了，为什么要转字符串？会这么问，是因为你还没被“跨系统传输图片”这件事折磨过。实际开发中遇到最多的几类情况是这样的：
第一类是接口传输。你做前后端分离，或者对接第三方 API，有时候就是没有办法直接在 multipart 表单里塞二进制文件，或者接口早就定义成了 JSON 格式。这个时候 Base64 字符串就是最省事的通用格式，随 JSON 一起走，不需要额外解析文件流。
第二类是数据库存储。有些场景你不希望把图片落成磁盘文件，而是想直接以文本字段存进数据库，比如存一个小图标、一张小程序码、一个签名图。虽然我一直不建议把大图存数据库，但小图片存文本字段确实方便，尤其配合定时任务、缓存系统，省掉了一堆文件服务器的烦恼。
第三类是在线预览和邮件嵌入。HTML 里的 data URI 大家应该见过，形如data:image/png;base64,....，把图片 Base64 之后拼上这个前缀，前端直接放进<img>标签的 src 属性就能显示，不用发请求、不用接口、不用下载。邮件客户端里很多内嵌图也是这么干的，否则你发出去的邮件，对方收到时经常看不到图片。
第四类是图片在内存里生成、压根不需要落盘。你用 Pillow 动态画图、做验证码、给图片加水印，生成出来的对象只在内存中；如果转成 Base64 字符串，就可以把这个结果直接打成日志、发给消息队列、或者存进 Redis。整个过程不走磁盘，干净利落。
1.2 Base64的本质：把二进制包装成文本，但别指望它压缩
Base64 这个概念对新手来说好像很神秘，其实说白了：它就是一种把二进制数据变成 ASCII 文本的编码规则。原理是把每 3 个字节（24 bit）拆成 4 组，每组 6 bit，然后映射到A-Z a-z 0-9 + /这 64 个可打印字符上，不够 3 字节的末尾补=。
用生活里的例子类比：二进制数据就像你要寄送的精密零件，网络和很多存储系统并不是一个适合裸寄零件的环境，于是你把它放进一个统一的、标准尺寸的防震包装盒里，这个包装盒就是 Base64 编码。对方收到后，只需要拆开包装（解码）就能还原成原来的零件。整个过程玩的是“重新包装”，不产生任何压缩效果，反而因为每 3 字节变成 4 个字符，体积会膨胀约 33%。
这个“膨胀 33%”会带来什么实际影响？一张 10MB 的图片，转成 Base64 字符串之后大约是 13.3MB；如果是对一个大视频或者大型二进制流做这种转换，内存和传输开销都会明显上升。所以你在工程化的时候必须心里有数：这是一笔数据体积的“附加税”，换取的是传输和存储上的极大便利。后面第 6 节我会专门讲怎么把这笔“税”省着点交。
2. Pillow转Base64的核心操作：从Image对象到字符串
2.1 最简代码：转换三步走
先给出一段可以直接跑起来的最小完整示例。这里强调一点，现在的项目里直接 pip install PIL 是装不上的，因为最初的 PIL（Python Imaging Library）早已停止维护，大家现在用的是它的兼容分支 Pillow，导入语句仍然是from PIL import Image。你只要 pip install Pillow 就行。
from PIL import Image import base64 import io # 第一步：用Pillow打开图片文件，得到一个Image对象 img = Image.open("demo.png") # 第二步：把Image对象保存到内存缓冲区，而不是保存到磁盘 buffer = io.BytesIO() img.save(buffer, format="PNG") # 第三步：把缓冲区里的二进制数据取出来，做Base64编码，再转成字符串 base64_str = base64.b64encode(buffer.getvalue()).decode("utf-8") print(base64_str)核心就是这么三行逻辑：打开 → 写入内存 → 编码。很多网上的教程会教你“先把图片保存成临时文件，再读文件，再编码”，虽然也能跑通，但会留下两个问题：一是产生临时磁盘文件污染系统，二是在高并发或者容器环境下，反复读写磁盘性能很差。而io.BytesIO()是在内存里模拟了一个文件对象，你的图片数据不落盘，整个过程完全在内存中完成，干净且高效。
2.2 BytesIO为什么是必需品
理解BytesIO是理解整个转换流程的关键。Pillow 的Image.save()方法需要接收一个文件路径或者一个文件对象。文件对象除了真实磁盘文件（open("xxx.png", "wb")返回的对象），也可以是内存虚拟文件。io.BytesIO()创建的就是这样一个虚拟文件，你用save()往里面写数据，之后用getvalue()可以把里面所有的字节一次性取出来。
为什么不能直接用img.tobytes()呢？这个问题很多人问过。Image.tobytes()返回的是图像的原始像素数据，也就是说它是图像解码后的裸 RGB/RGBA 数据，不包含 PNG 或 JPEG 的压缩编码信息。直接把这段裸数据转成 Base64，不仅体积巨大（一张图片的像素数据远远大于压缩后的文件数据），而且别人拿到之后无法直接作为图片文件打开，还需要额外知道尺寸、通道数、颜色空间等一大堆元数据。这就是为什么我们必须经过img.save(buffer, format="PNG")这一步，它会把像素数据按 PNG 规则压缩编码，生成是完整的、标准可识别的图像文件格式。
2.3 保存格式必须显式指定：format参数的门道
img.save(buffer, format="PNG")里的format参数最好永远不要省略。为什么？因为 Pillow 自动判断格式的逻辑通常是靠文件扩展名来的，但BytesIO没有文件名，如果你不指定format，保存时大概率会直接报错，或者保存成默认的格式结果和你的预期不一致。所以一个实用的习惯是：永远显式传format="PNG"或format="JPEG"或format="WEBP"。
这里我把不同格式的特征列个表格，方便你按场景选：
| 格式 | 是否支持透明通道 | 压缩类型 | 典型体积 | 适合场景 |
|---|---|---|---|---|
| PNG | 支持 | 无损 | 中等偏大 | 图标、截图、需要透明的图 |
| JPEG | 不支持透明 | 有损 | 较小 | 照片、无明显边缘的图 |
| WEBP | 支持透明 | 有损/无损可选 | 通常最小 | Web前端展示、需要极致压缩 |
如果你把 RGBA 模式的图用 JPEG 格式保存，Pillow 会报错或者强制丢透明通道，这个我放到下一节单独讲，因为这是新手最容易栽的第一个坑。
3. 转换过程中的常见事故：模式、格式与缓冲区
3.1 RGBA保存成JPEG：模式转换不能省
代码跑通了之后，你很快会遇到第一个诡异场景。某天你生成了一张带透明背景的图片，心里想着“我要把它转成 JPEG 格式的 Base64”，结果一执行，Pillow 直接甩给你一个异常：
OSError: cannot write mode RGBA as JPEG这个错误的原因很简单：JPEG 格式本身不支持 alpha 透明通道，它只有 RGB 三个颜色通道。而 PNG 支持，RGBA 模式恰好就是要写 PNG 的。解决方案就是在保存之前手动转模式：
img = img.convert("RGB") buffer = io.BytesIO() img.save(buffer, format="JPEG", quality=85)这里有个细节要提醒你：透明区域在转换时会被填充成黑色还是白色，取决于你的图片内容。绝大多数情况下，透明背景转 JPEG 后直接变黑，这是很多人不满意的地方。如果你希望透明区域变成白色背景，那就不能直接.convert("RGB")，得先创建一个白底 RGB 画布，再把原图贴上去：
from PIL import Image background = Image.new("RGB", img.size, (255, 255, 255)) background.paste(img, mask=img.split()[-1]) # 用alpha通道作为蒙版 img = background这段代码我是踩过一次坑才记牢的。平时做验证码、小程序码截图时，透明背景转白底几乎都是必须的，否则前端显示出来就是一团黑疙瘩。
3.2 Base64里的换行符和数据前缀要怎么处理
第二个大坑是字符串“不干净”。来自不同来源的 Base64 字符串格式可能不同，直接拿去解码会出问题。
第一种情况是标准库的base64.encodebytes()生成的字符串会每隔 76 个字符插入一个换行符，如果你用b64encode()则不会。但是当你在项目里读到别人代码生成的字符串，或者从日志、数据库、配置文件里拿到一段 Base64 时，里面可能藏了不少换行和空格。
第二种情况是带前缀的 data URI。很多前端代码直接就把data:image/png;base64,xxxx整个字符串传给了后端。这时候如果你直接base64.b64decode(whole_string)，会抛异常或者返回一堆乱码数据，因为前缀部分并不是合法的 Base64 字符。
通用的处理方案如下：
import base64 import re def clean_base64(s: str) -> str: # 去掉 data URI 前缀 if s.startswith("data:"): s = s.split(",", 1)[-1] # 去掉空白字符 s = re.sub(r"\s+", "", s) return s def b64_to_bytes(s: str) -> bytes: cleaned = clean_base64(s) return base64.b64decode(cleaned)更稳妥一点的做法是用base64.b64decode(s, validate=False)。validate=False是默认值，它会在解码时忽略非字母表字符，比如换行符。但为了可读性和避免意外，我建议还是自己做清洗，因为有时候字符串里混进了不合理的字符，b64decode的“宽容模式”会把错误也吞掉，让你找不到真正的问题在哪。
3.3 BytesIO的“指针”陷阱：getvalue还是read
第三个坑比较隐蔽，但它能让你的 Base64 字符串变成一截空串。先看这段代码：
buffer = io.BytesIO() img.save(buffer, format="PNG") # 错误写法 data = buffer.read() base64_str = base64.b64encode(data).decode("utf-8")如果在这之前你已经在buffer上做过一次seek(0)和read()，那没问题；但如果只是save()之后直接read()，你会震惊地发现data是b''。原因在于save()写完之后，文件指针停在缓冲区末尾，也就是说文件的“读写头”已经移动到最后一个字节的后面了。此时调用read()，从当前位置一直读到末尾，自然只能读到空。
正确做法是使用getvalue()，它会返回缓冲区的全部内容，完全不管你当前文件指针在哪儿：
base64_str = base64.b64encode(buffer.getvalue()).decode("utf-8")或者使用seek(0)配合read()：
buffer.seek(0) data = buffer.read()除非你要在这个缓冲区上做多次读写，否则我个人建议一律用getvalue()，简洁安全，不容易出幺蛾子。
3.4 如果图片里有中文文字，PIL默认字体直接翻车
这里额外再说一个和 PIL 转换强相关的高频问题：你要在图片上画文字，然后再转 Base64。很多人在 Pillow 里直接用默认字体ImageFont.load_default()，画英文还行，一画中文就出现一堆方框“□□□□”。这不是编码问题，而是 Pillow 内置默认字体根本不包含中文字形。
解决办法是加载系统中文字体文件。Windows 上常见的是C:/Windows/Fonts/msyh.ttc（微软雅黑），macOS 上是/System/Library/Fonts/PingFang.ttc，Linux 上要看你装了什么中文字体，常见路径是/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc。
from PIL import ImageFont font = ImageFont.truetype("C:/Windows/Fonts/msyh.ttc", 32)加载成功后再用draw.text()画中文，最后按前面的流程保存成 PNG 再转 Base64，出来的字符串前端拿到就能显示正常。很多时候我们排查“Base64图片显示成乱码”“图片上文字是乱码”，根源不是转换过程，而是图片生成时字体加载失败。
4. 反向操作：把Base64字符串还原成图片
4.1 解码后从BytesIO重新打开
处理完图片转字符串之后，你大概率还需要做反向操作：收到一段 Base64 字符串，把它还原成图片对象，或者存成文件。和正向流程相反，核心就三步：解码 → 放进 BytesIO → 用 Image.open 读取。
import base64 import io from PIL import Image def base64_to_image(base64_str: str) -> Image.Image: # 清洗字符串 if "," in base64_str and base64_str.startswith("data:"): base64_str = base64_str.split(",", 1)[-1] base64_str = base64_str.strip() # 解码得到二进制数据 img_bytes = base64.b64decode(base64_str) # 丢进BytesIO，让Pillow从内存中解析 img = Image.open(io.BytesIO(img_bytes)) return img注意这里Image.open()并不会立刻把图片的全部像素数据加载进内存，它有一个“懒加载”机制，读取文件头、尺寸、格式等信息之后，等真正用到像素（比如img.load()、img.save()、img.size之外的像素操作）才会完整解码。这在处理大批量图片时能省不少内存，但也会带来一个副作用：BytesIO缓冲区的生命周期必须保持到图片真正被加载或复制为止。也就是说，你不能在一个函数里打开Image.open(io.BytesIO(img_bytes))，接着函数结束了BytesIO被回收，然后再去用img.load()，这样是会出问题的。
一个粗暴但稳妥的办法是打开后立刻复制一份像素数据：
img = Image.open(io.BytesIO(img_bytes)).copy().copy()会强制把图片完整解码成内存中的独立对象，此时 BytesIO 的生命周期就不再影响后续使用了。代价是图片数据会完整加载到内存，大图会吃不少内存，但换来了心安。
4.2 保存到磁盘的正确姿势
如果只是想把 Base64 还原的文件以 PNG/JPEG 形式存到磁盘上，最简单的做法是：
with open("restored.png", "wb") as f: f.write(base64.b64decode(cleaned_str))这样写出来的文件就是标准的图片文件，能打开、能预览。不用绕一圈再去用img.save()，因为解码后的bytes就是原始图片文件的全部字节，直接落盘最效率。当然如果你还要对还原出来的图做处理，比如改大小、加滤镜，那就用 4.1 节的Image.open(io.BytesIO(...))方案。
4.3 不要忽略字符串清洗
我在实际接口联调里见过最快翻车的情况，就是前端传过来的 Base64 字符串里带了一段前缀data:image/jpeg;base64,，后端同事没处理，直接解码，结果整个程序报错。也有从 Excel 单元格里读出来的字符串自动换行，卡了你半天。所以无论是正向还是反向，写一个clean_base64()工具函数放在公共模块里，是个非常划算的小投资。
5. 真实场景落地：data URI、HTTP接口和数据库存储
5.1 前端预览专用：data URI拼法
在前后端分离的项目里，我们经常要生成一个验证码图片回显给前端。传统做法是后端把图片接口暴露出去，前端用<img src="/captcha">去加载。但其实也有不少项目直接用 Base64 字符串返回，把整个图片的 data URI 发给前端。
data URI 的拼法非常简单：
data_uri = "data:image/png;base64," + base64_str前端拿到之后直接img.src = data_uri就能显示。这里的重点是image/png必须和你保存图片时用的格式对应。如果你保存的是 JPEG，那就要拼data:image/jpeg;base64,...，否则部分浏览器会拒绝渲染或者显示异常。我在项目中会动态判断格式：
format_map = { "PNG": "image/png", "JPEG": "image/jpeg", "WEBP": "image/webp", } def image_to_data_uri(img: Image.Image, fmt: str = "PNG") -> str: buffer = io.BytesIO() if fmt.upper() == "JPEG" and img.mode != "RGB": img = img.convert("RGB") img.save(buffer, format=fmt.upper()) mime = format_map.get(fmt.upper(), "image/png") return f"data:{mime};base64,{base64.b64encode(buffer.getvalue()).decode()}"5.2 HTTP接口传图：Base64字段还是二进制流？
既然做接口设计，迟早要面临一个选择：图片用 Base64 放在 JSON 里传，还是用 multipart/form-data 走二进制流？
我的经验是分场景。如果是小图片（几十KB到几百KB），传 Base64 非常方便，因为传输、日志、mock、调试都极其直观，任何 HTTP 调试工具都能直接看。但如果图片经常超过 1MB，甚至几 MB，我建议还是老实走二进制上传接口，因为 33% 的体积膨胀在带宽成本上不是小数，而且 JSON 字段本身对大字符串的解析也有额外开销。
如果要传 Base64，比较推荐的 JSON 结构一般是：
{ "image": "data:image/png;base64,...", "filename": "demo.png" }后端把多个图片字段放在一个 JSON 里，也支持批量上传。注意如果字段里已经带了 data URI 前缀，后端不要重复拼前缀；如果不带，后端要根据扩展名或者图片实际格式判断 MIME 类型。这个统一约定一定要写在接口文档里，我在项目里吃过好几次“我加前缀你不识别、你还加前缀重复了”的误会。
5.3 数据库存储的取舍
关于图片塞数据库，我的态度是有条件就别塞，没条件就只塞小图。
把 Base64 字符串直接存进 MySQL 的 TEXT 字段，或者 MongoDB 的字符串字段，确实省事——不折腾文件服务器、不搞对象存储、也避免了应用多副本之间文件不同步的问题。但你必须注意到两个代价：
第一是体积。原本 100KB 的图片存成 Base64 后约 133KB，如果你存一万张，额外多出来 330MB 的存储空间，后面备份、迁移、查询都会变慢。
第二是渲染性能。前端从数据库拎出来一整个大字符串再在前端解码渲染，体验远不如直接用对象存储 URL 走 CDN。所以我的建议是：只把极小图标、缩略图、临时验证码这类的图片用 Base64 存数据库，大图一律走文件存储或对象存储，数据库里只存 URL 或者对象存储的 key。这是性能和代码复杂度综合下来最平衡的路线。
5.4 拼接一个完整的上传工具函数
把前文的所有逻辑整合起来，我日常项目里常用的工具函数长这样：
import base64 import io import re from PIL import Image def clean_base64(s: str) -> str: if s.startswith("data:"): s = s.split(",", 1)[-1] return re.sub(r"\s+", "", s) def pil_image_to_base64(img: Image.Image, fmt: str = "PNG", **save_kwargs) -> str: if fmt.upper() == "JPEG" and img.mode != "RGB": img = img.convert("RGB") buffer = io.BytesIO() img.save(buffer, format=fmt.upper(), **save_kwargs) return base64.b64encode(buffer.getvalue()).decode("utf-8") def base64_to_pil_image(s: str) -> Image.Image: img_bytes = base64.b64decode(clean_base64(s)) return Image.open(io.BytesIO(img_bytes)).copy() def base64_to_bytes(s: str) -> bytes: return base64.b64decode(clean_base64(s))另外给你一个经常用到的自定义 kwargs 示例：如果保存 JPEG 想控制质量，就调用pil_image_to_base64(img, "JPEG", quality=80)；想保存 WebP 并设置无损，可以pil_image_to_base64(img, "WEBP", lossless=True)。**save_kwargs会被直接传给img.save()，这就是灵活性的来源。
6. 性能与工程化：别等大图教做人
6.1 先缩后编：用thumbnail控制体积
如果你要认真使用这个方案，最后一定要解决的问题是：图片太大，Base64 字符串太长，接口慢、前端卡、日志被刷屏。
我推荐的做法是在编码之前先做一次缩放。Pillow 里最常用的是thumbnail()，它会在保持宽高比的前提下，把图片最长边缩到指定尺寸，并且直接修改原对象：
img.thumbnail((1024, 1024), Image.Resampling.LANCZOS)Image.Resampling.LANCZOS是当前 Pillow 里质量最好的缩放算法之一，在高分辨率原图缩小时观感损失小。注意thumbnail()只缩小、不放大，如果图片本身小于 1024×1024，它不会把图变大，这一点非常贴心。
也有不少教程推荐resize((700, 500))，但resize会让你手动指定精确尺寸，很容易破坏宽高比导致图片变形。日常使用我都优先用thumbnail()，只有当业务明确要求固定尺寸的封面图时才用resize()加ImageOps.fit()裁剪填充。
6.2 JPEG质量参数：quality与optimize的实测心得
选完格式，压缩还有不少文章可做。JPEG 的核心参数是quality，取值范围 1 到 95，默认 75。我在实际项目里测试过：对于大多数界面截图和照片，quality=80左右肉眼几乎看不出区别，但体积比默认 75 差距不大；如果把quality降到 60，体积可以再降 30% 左右，细节边缘开始有轻微损失，适合用在缩略图上。
还有两个参数值得认识。optimize=True会让编码器做更细致的优化，体积能进一步降一点，但编码速度会变慢；progressive=True会生成渐进式 JPEG，在低速网络下用户体验更好，占用的体积基本不变。如果这份 Base64 数据要传给前端展示，我个人习惯用quality=80, optimize=True, progressive=True，速度和体积综合表现都不错。
PNG 就没那么多调参空间了，它是无损格式，体积主要取决于图像内容。真需要压缩 PNG 时，可以转成 WebP 无损模式，通常能比 PNG 小 20% 左右：
img.save(buffer, format="WEBP", lossless=True)WebP 对现代浏览器的支持已经非常好，如果是内部系统或者可控浏览器环境，直接用 WebP 是性价比很高的选择。
6.3 内存峰值管理：批量处理时别一口气全干
批量处理图片转 Base64 时，最容易发生的是内存爆炸。原因很简单：你每处理一张大图，图片原始像素数据加编码缓冲区的总和可能超过图片文件的十几倍。一张 5000×5000 的 PNG，文件可能只有 2MB，但解码后在内存里的 RGBA 原始数据是 5000×5000×4 = 100MB，再叠加编码后的 BytesIO 缓冲区，内存瞬间就上去了。
应对策略主要有三条：
第一，批量任务不要并发开太高。如果你用的是进程池，默认并发数改成 CPU 数的一半或者经验值 4~8，避免多张大图同时抢占内存。
第二，处理完一张立刻释放引用。不要把所有 Image 对象或 Base64 字符串都攒在一个列表里。写循环时最好处理完就存出去或传出去。如果你用的是 Jupyter Notebook 这种自带变量保留的环境，特别容易忽略这一点，变量越堆越多。
第三，对大图先缩略再编码。这条和第 6.1 节呼应，缩略本身就是最好的内存优化。一个 1024×1024 的 RGB 图，原始像素数据只有 3MB 左右，怎么处理都不会太失控。
6.4 什么时候真的不该用Base64
讲了这么多，最后必须说点劝退话。有几种场景我强烈不建议用 Base64：
一是大文件传输。比如视频、压缩包、安装包，你宁可花时间去搭文件服务或者对象存储，也不应该用 Base64 徒增 33% 的体积和带宽。
二是需要频繁读写的高性能缓存场景。Base64 编解码本身有 CPU 开销，如果你每秒处理几千张图，这成本不容忽视。能用二进制直接用二进制，Redis 的 string 类型也支持存储 bytes，不需要转文本。
三是图片要长期存储且数量巨大。存对象存储，给文件一个 key，比存百万级 Base64 字符串在数据库里要稳健得多。数据库字段再宽也有长度限制，超长字符串写入、索引、备份都会出问题。
这套方案最适合的领域，还是小体积图片的跨系统传输、动态图片的接口返回、前端 table 预览、邮件和 Markdown 内嵌图。边界清楚了，用起来就不纠结。
至少在我自己的项目里，这一套“PIL + BytesIO + Base64”的组合已经稳定跑了好几年。最后再分享一个小经验：转换字符串之前，先用img.size和img.mode打印出来看一眼，很多奇怪问题其实就是这两个属性没符合预期。把最基础的信息确认好，你的图片转换之路会顺畅不少。
