photoimage 不支持 jpg 是 tk 底层限制，因其原生仅内置 gif、ppm/pgm、部分 bmp 解码器，未链接 libjpeg；加载 jpg 会静默失败或报“pyimage1 does not exist”；pil.imagetk.photoimage 通过 pillow 解码再封装绕过该限制，但需强引用和正确路径。
PhotoImage 不支持 JPG 是 Tk 底层限制，不是 Python 或 Pillow 的问题，也和你代码写得对不对无关——它压根没这个解码能力。
PhotoImage 为什么加载 JPG 会静默失败或报 pyimage1 does not exist
Tk 的原生图像子系统（X11 / Windows GDI / macOS Core Graphics 对接层）在设计时只内置了少数几种格式的解码器：
-
GIF（含简单动画和透明） -
PPM/PGM（纯文本/二进制位图，无压缩，用于测试） -
BMP（部分 Tk 版本支持，但不稳定）
JPG、PNG、WebP 等现代格式需要额外链接 libjpeg、libpng 等外部库，而标准 Tk 发行版（包括 Python 内置的 _tkinter 模块）默认不带这些依赖。
所以当你写 tk.PhotoImage(file="a.jpg")：
- 不会立刻报错（Tk 尝试读文件头，发现不匹配就放弃）
- 返回一个“空壳”对象，后续绑定到
Label或Canvas时才触发TclError: image "pyimage1" doesn't exist - 控制台可能没输出，尤其在 IDE 中容易被忽略
为什么不能靠升级 Python 解决
Python 3.12、3.13 甚至未来版本的 tkinter 依然沿用系统级 Tk 库（通常是 8.6.x）。
Tk 官方从未承诺增加 JPG/PNG 原生支持——这不是 bug，是明确的设计取舍。
你看到的“某些教程说新版支持 PNG”，大概率是误把 PIL.ImageTk.PhotoImage 当成了原生组件。
PIL.ImageTk.PhotoImage 是怎么绕过这个限制的
它不依赖 Tk 的解码器，而是：
- 用 Pillow 的
Image.open()读取 JPG 文件（调用 libjpeg） - 在内存中解码为 RGBA 或 RGB 像素数组
- 把像素数据按 Tk 能理解的内部格式（
PhotoImage的 C 结构体）重新打包 - 最终生成一个真正有效的 Tk 图像 ID
关键点在于：这个过程完全脱离 Tk 的原生解码链路，所以 JPG、PNG、WebP、TIFF 全都能过。
容易被忽略的两个致命细节
-
ImageTk.PhotoImage对象必须被强引用住，否则 Python GC 会回收它，Tk 就“丢图”——最简方案是写label.image = img，而不是只写label.config(image=img) - 路径里有中文、空格、相对路径未对齐工作目录，会导致
Image.open()直接抛FileNotFoundError，但错误被吞掉或显示为黑框/空白，别急着怀疑 Pillow
真正的障碍从来不在格式本身，而在引用管理和路径控制。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
