base64.b64encode()必须传入bytes，需用"rb"模式读取图片；解码时须补全padding并用"wb"写入；大图应避免一次性read以防内存溢出；base64图片无法被cdn缓存且不支持懒加载。
用 base64.b64encode() 编码图片文件必须读成 bytes
直接传入文件路径或字符串会报 TypeError: a bytes-like object is required, not 'str'。Python 的 base64.b64encode() 只接受 bytes，不接受文本或路径。
正确做法是用二进制模式打开图片，再传给编码函数：
import base64
<p>with open("photo.jpg", "rb") as f:
img_bytes = f.read()
encoded = base64.b64encode(img_bytes).decode("utf-8")</p><h1>得到的 encoded 是字符串，可用于 HTML src 或 API 提交</h1>- 必须用
"rb"模式打开，"r"会解码为 str，触发类型错误 -
.decode("utf-8")是为了把编码结果从bytes转成常用字符串；若需保留 bytes（比如写入二进制文件），可省略这步 - 常见误操作：对 PIL.Image 对象直接调用
b64encode()—— 它不是 bytes，得先用.tobytes()或保存到BytesIO
用 base64.b64decode() 还原图片要补全 padding 并写入 binary 文件
Base64 字符串末尾的 = 是 padding，缺失时 b64decode() 会抛 binascii.Error: Incorrect padding。尤其从 URL、HTML 属性或某些 API 返回的 Base64 常被截断或省略 padding。
安全解码需手动补全：
立即学习“Python免费学习笔记（深入）”；
import base64
<p>encoded_str = "iVBORw0KGgoAAAANSUhEUgAA..." # 可能缺 = 的字符串</p><h1>补齐长度为 4 的倍数</h1><p>missing_padding = len(encoded_str) % 4
if missing_padding:
encoded_str += "=" * (4 - missing_padding)</p><p>img_bytes = base64.b64decode(encoded_str)</p><p>with open("restored.png", "wb") as f:
f.write(img_bytes)</p>- 只靠 try/except 捕获再重试不够鲁棒；padding 规则固定，主动补更可靠
- 写入必须用
"wb"，用"w"会因编码问题损坏图片 - 如果 Base64 前缀含
data:image/png;base64,，得先用.split(",", 1)[1]切掉前缀，否则解码失败
大图编码别用 read() 一次性加载，内存会爆
一张 20MB 的 PNG 图片，经 Base64 编码后体积增大约 33%，且 Python 会同时在内存中存原始 bytes 和编码后字符串——实际占用超 50MB。对批量处理或服务端场景很危险。
- 小图（f.read() 最简单
- 中大图（>2MB）：改用
base64.encodebytes()，它支持分块读取并自动换行（虽然你通常不需要换行，但它的实现内部做了流式处理） - 真正大图或不确定大小：用
io.BytesIO+ 分块读取 + 手动 feed 给b64encode，但多数情况没必要——优先考虑是否真需要 Base64，还是该传 URL 或二进制流
Web 场景下 Base64 图片的 real-world 限制
浏览器支持没问题，但实际用起来有几个硬伤：
- 无法被 CDN 缓存：Base64 是内联数据，每次 HTML 加载都重复传输，没复用
- HTTP/2 推送和 preload 不适用：浏览器不识别 data URL 为独立资源
- 图片懒加载（
loading="lazy"）失效：data URL 立即解析，失去延迟加载意义 - 调试困难：Chrome DevTools 的 Network 面板里看不到 Base64 图片的尺寸、类型、加载时间，只有 HTML 文本长度
除非是极小图标（
。
