直接说结论overlay 在相机和图像处理里不是新概念但很多人把它理解窄了。我这次围绕“绵绵很好_overlay”这个项目把 overlay 的常见玩法整理了一遍最值得关注的不是某个炫酷滤镜而是它能把透明图层、文字、时间戳、网格信息稳定地合成到一张图上。适合正在做相机工具、图片批处理脚本、前端 Canvas 合成或者单纯想把照片加上自定义叠加层的人看。下面不绕弯子按实际落地顺序拆开讲。1. 先搞清楚 overlay 到底是什么以及它解决什么问题1.1 overlay 不是滤镜也不是贴纸那么简单overlay 通常翻译成“叠加层”或“覆盖层”。常见的理解是在一张底图上面再放一层内容这层内容可以带透明度可以通过混合模式决定和底图怎么融合。很多人一提到 overlay 就想到贴纸、表情、水印其实这只是最表层用法。在实际项目中overlay 更关键的是“把不同来源的信息统一到一张图上”。底图是一张照片叠加层可以是一张带 alpha 通道的 PNG也可以是一段动态绘制的时间文本还可以是相机实时取景时画的网格线。这些东西并不是简单贴上去它们涉及坐标、透明度、混合方式、图层顺序、色彩空间和性能占用。“绵绵很好_overlay”这个项目名字里带着一种个人感很像是在做一个私人相机或图片美化工具时给叠加层模块起的代号。这类项目核心要解决的通常是三个问题怎么把 overlay 内容显示在正确位置。怎么保证叠加层的透明效果自然不让画面看起来像两张图片硬拼在一起。在相机实时预览或批量处理时怎么让 overlay 不拖垮性能。所以如果你只是把 PNG 贴到图上那不算真正掌握 overlay。你需要理解透明通道理解坐标系理解不同混合模式对画面亮度、对比度、颜色倾向的影响。1.2 常见 overlay 应用场景我整理了四个最常见的使用场景覆盖相机、图片处理、前端和批量工具领域。第一个场景是相机实时预览叠加。很多拍照 App 会在取景画面上显示网格线、水平仪、快门信息或时间戳。这些内容不能直接写入相机传感器数据通常会在预览层上面再画一个 overlay 视图。用户能看到但最终保存时可以选择是否把 overlay 合成进照片。这个场景对延迟非常敏感overlay 的绘制必须跟得上预览帧率否则取景画面会卡顿。第二个场景是照片后期合成。比如给照片加半透明水印、拍立得相框、日期章、天气信息或地理位置。这些工作适合在后台完成不要求实时但要求合成质量高尤其是文字边缘要清晰透明区域不能出现黑边或白边。第三个场景是前端网页里的 Canvas 和 CSS 叠加。网页上经常需要把用户头像、二维码、宣传语叠加到一张底图上再生成分享图片。这个场景和本地图像处理类似但要注意跨域、字体加载、Canvas 像素和 CSS 像素的换算以及不同浏览器对 alpha 通道合成结果的差异。第四个场景是批量数据可视化叠加。比如给一批无人机航拍图叠加坐标和时间戳给截图叠加来源标记给视频关键帧叠加字幕。这个场景最容易被低估因为单个文件都很简单但一旦文件数量到几百上千叠加层的统一性、命名、失败重试就会成为主要工作量。这四个场景在后面都会拆到先说结论overlay 的核心价值不是“加一层东西”而是“可控地、可重复地、可批量化地把一层真实信息融合到另一张图上”。1.3 为什么很多人做 overlay 时容易翻车我见过不少翻车案例问题往往不在底层图片而在 overlay 本身。一类问题是透明通道处理错误。PNG 叠加层如果保存时丢失 alpha 通道或者用了不支持的格式合成结果就会变成不透明矩形块把底图整个盖住。二类问题是坐标基准不一致。相机会把图片顺时针旋转 90 度保存而代码里还在用原始宽高计算 overlay 位置。尤其是竖拍模式下时间戳和网格线经常偏到照片外面。三类问题是混合模式选错。overlay 看着像“叠加上去”但实际上有 normal、multiply、screen、overlay、soft-light 等一堆模式。选错后同一张透明层在深色背景和浅色背景上会出现完全不同的效果。很多人抱怨“叠加后颜色变了”大概率不是颜色失真而是混合模式不符合预期。四类问题是性能问题。实时预览或视频帧处理中如果每帧都新建一个大尺寸位图再合成内存抖动会非常明显手机发热、卡顿、掉帧都从这里来。正确做法是预先创建 overlay 图层只更新内容变化的部分。所以在继续往下看之前建议先把 overlay 理解成“图层系统”的一部分。它和底图之间的关系不只是前景和背景而是由透明度、混合模式、坐标、绘制顺序共同决定的像素运算过程。2. 相机场景下 overlay 最值得先试的三个方向2.1 实时预览叠加时间戳、地点、网格线如果你在做一个相机类小工具实时预览 overlay 是最容易出效果的方向。最典型的三个元素三分线网格、时间戳、地点标签。网格线的作用是辅助构图。实现时不需要单独的图片文件直接用绘制 API 在预览层上方画出几条直线就可以。关键是线条颜色和透明度。白色线在亮色区域看不清深色线在暗部看不清。比较通用的做法是用半透明白色加一点投影或者动态判断当前帧的平均亮度来切换线条颜色。别小看这一点很多相机 App 的网格线不管环境亮度如何都保持一致白天可能还能接受夜景时会非常吃力。时间戳和地点标签的布局也要提前考虑。常见位置是左下角或右下角但要避免遮挡人脸、重要物体和系统返回区域。另一个容易忽略的问题是字体大小。同样是 14 号字体在 1080P 图上和 4K 图上视觉效果完全不同。如果 overlay 内容要随照片分辨率缩放字体最好按图片宽度比例计算。实时预览里还有个细节叠加层要区分“仅显示”和“合成到保存图”。不少相机 App 允许用户预览时看到时间戳但保存时选择不把时间戳写进照片。如果代码里直接把预览层和保存逻辑绑定后面想拆开会很麻烦。我建议从一开始就把两个状态分开一个 overlay 只做预览显示另一个 overlay 做最终合成这样后续扩展贴纸、滤镜都方便。2.2 照片后期叠加半透明水印和相框照片后期叠加是另一类常用场景。这里不需要实时反而应该把质量放在第一位。半透明水印是最典型的案例。普通做法是直接把一张水印 PNG 贴到照片角落透明度设为 0.3 或 0.5。这种做法能出效果但有几个细节值得优化。第一水印图片的尺寸要匹配目标图像。如果直接拉伸文字会变形边缘会虚。更好的做法是保持宽高比按比例缩放再放到固定边距的位置。第二水印透明度不是越低越好。0.2 以下的透明度在电脑屏幕上看可能还明显但在手机屏幕上几乎看不见。如果你希望水印既能防误用又不影响画面透明度在 0.3 到 0.5 之间通常比较稳。当然这个范围不是一个硬标准要看画面亮度和水印颜色。第三水印和底图之间的混合模式。默认用 normal 就好但如果水印是深色文字、底图又是深色调可以试试 screen 或 soft-light 模式让水印更自然地融入暗部区域。这里的前提是你已经理解混合模式的行为例如 screen 会提亮整体multiply 会变暗overlay 会增强对比度。如果你不清楚为什么要换就继续用 normal先保证结果可控。相框叠加也是后期常用的功能。实现思路和普通贴纸类似把一张带透明区域的相框 PNG 放在照片上面。但要注意相框图片的分辨率必须和输出图片匹配否则边缘会模糊或出现锯齿。很多拍立得风格的相框不只是一个方框还包含手写文字、日期、小图案这些东西的布局都要在相框图里预先设计好。2.3 视频或连续帧叠加批量复制注意资源占用从单张照片进入视频或连续帧场景overlay 的使用方式会发生明显变化。视频本质上是一连串图片。给视频叠加字幕、时间码或水印时最常见的错误做法是每一帧都重新从磁盘读取 overlay 图片再重新创建合成画布。小分辨率视频可能看不出问题但一旦处理 4K 视频或长视频磁盘读取和内存分配会成为瓶颈。更好的做法是先一次性加载 overlay 内容到内存并把它预处理成和目标视频帧兼容的格式。然后逐帧处理时只需要复制底图、把 overlay 图按 mask 或 alpha 混合上去、释放帧资源。如果 overlay 内容本身是动态的比如每秒变色或移动位置也不要每帧从零创建而是只更新变化的坐标和颜色状态。连续任务还有一个容易被忽略的问题输出路径和命名。视频帧通常有几千张如果输出命名不统一后续拼接视频时会出现顺序错乱。建议使用至少 5 位数字补零例如 frame_00001.png 到 frame_12000.png。同时处理好失败重试某一帧合成失败不要直接中断整个任务先把错误帧记录到日志或独立目录重试时只处理这些帧。如果你只是学习先不用做很复杂的断点续跑。能把单帧 overlay 跑通再处理顺序命名最后加失败重试这个顺序比较合适。3. 用 Python 写一个最小可用的 overlay 合成流程3.1 环境准备图像处理领域的 overlay 合成最常见的技术栈是 Python 加 Pillow以及 OpenCV。Pillow 更适合处理静态图片OpenCV 适合处理视频帧、实时数据以及需要用到大量矩阵运算的场景。做相机工具的话还会接触到 Android 的 Bitmap / Canvas或者 iOS 的 CoreGraphics但原理都一样。先准备环境。如果只是想验证 overlay 的基本逻辑安装两个库就够了pip install pillow opencv-pythonPillow 负责加载图片、创建透明图层、输出结果。OpenCV 可以用来读取摄像头帧、处理视频、做一些颜色空间转换。这两个库并不冲突很多项目会混合使用。这里要注意 Python 版本。常见环境下建议使用 Python 3.8 以上版本Pillow 和 OpenCV 的预编译包更新更快。如果你用的是很老的 Python 版本可能找不到匹配的依赖包报错时不要怀疑代码逻辑先检查版本。3.2 用 Pillow 实现单张透明叠加先做一个最简单的例子加载一张底图再把一张带透明区域的 PNG 水印叠加上去。from PIL import Image # 1. 加载底图转成 RGBA因为要处理透明度 background Image.open(photo.jpg).convert(RGBA) # 2. 加载 overlay必须是带透明信息的图片 overlay Image.open(watermark.png).convert(RGBA) # 3. 如果需要缩放 overlay保持宽高比 # 这里以底图宽度的 30% 作为目标宽度 target_width int(background.width * 0.3) target_height int(overlay.height * (target_width / overlay.width)) overlay_resized overlay.resize((target_width, target_height), Image.LANCZOS) # 4. 把 overlay 粘贴到底图上 # 例如放到右下角距离边距 20 像素 margin 20 pos_x background.width - target_width - margin pos_y background.height - target_height - margin # 关键把 overlay 作为 mask 传入 # 这样只有 rgba 的 alpha 通道参与融合黑色区域不会盖住底图 background.paste(overlay_resized, (pos_x, pos_y), overlay_resized) # 5. 转回 RGB 保存 result background.convert(RGB) result.save(result.jpg, quality95)这段代码看起来简单但有几个细节要重点理解。第一底图一定要转成 RGBA。如果底图是 JPG它本身没有 alpha 通道。直接 paste 一张带透明区域的 overlay在融合时不会自动正确处理。转成 RGBA 后Paste 操作才能利用 mask 参数按 alpha 混合。第二overlay 图片也要转成 RGBA。这个转换会保留它自带的 alpha 通道。如果原图是 JPG 或者没有 alpha 的 PNG转换出来的 alpha 是全不透明的所谓的“透明叠加层”其实和矩形贴纸没什么区别。第三paste 的第三个参数是 mask。这个误区很多人都会踩到。如果不传 maskPillow 会直接把 overlay 的不透明矩形区域覆盖到背景上透明像素会变成黑色或其他异常颜色。传入 overlay 本身作为 mask才能真正按 alpha 融合。第四保存时转回 RGB。因为最终输出 JPG 不支持透明通道RGBA 模式保存 JPG 有时会报错或出现奇怪结果。转成 RGB 再保存是更稳妥的做法。运行以后应该能看到底图的右下角出现一个水印水印的半透明区域能透出底图内容背景没有被黑色矩形盖住。如果背景变黑说明 mask 参数没有生效或者 overlay 本身没有 alpha。3.3 多图叠加和坐标对齐单张 overlay 跑通之后再试试多张 overlay。比如同时叠加一个相框、一个时间戳、一个地点标签。实现方式有两种一次 paste 一张依次执行或者先创建一个透明画布把所有叠加内容画上去再一次性合成。一次 paste 多个图层更直观适合叠加层数量不多的情况。优先级是底图在最下面后续 paste 的层级依次向上。代码里只要按顺序执行 paste 就可以。但要注意如果后一个 overlay 的面积比较大把前面已经贴好的内容盖住也属于正常现象。想让最上层的内容在最上就要放在最后一个 paste。坐标对齐部分最常见的需求是让几个 overlay 元素排列成一行。比如时间和地点都在左下角中间保持 10 像素间距。实现时不要手动改每个坐标先根据文本宽度计算一组坐标再统一 paste。from PIL import Image, ImageDraw, ImageFont bg Image.open(photo.jpg).convert(RGBA) # 创建一个透明画布用来绘制文字叠加层 text_layer Image.new(RGBA, bg.size, (0, 0, 0, 0)) draw ImageDraw.Draw(text_layer) font ImageFont.load_default(size48) time_text 2025-02-01 12:30 location_text 北京 # 测量文字尺寸再决定起始坐标 margin 30 line_height 60 current_y margin draw.text((margin, current_y), time_text, fontfont, fill(255, 255, 255, 180)) current_y line_height draw.text((margin, current_y), location_text, fontfont, fill(255, 255, 255, 180)) # 把文字层叠加到底图 bg.paste(text_layer, (0, 0), text_layer) bg.convert(RGB).save(result_with_text.jpg, quality95)这里我用了一个透明画布 text_layer而不是直接在背景上 draw.text。这样做的好处是如果后续需要单独调整文字层的整体透明度、模糊效果或移动位置只需要处理这一个图层。直接在背景上 draw 的话文字像素已经和背景融合再想改就难了。文字字体方面上面的 load_default 适合快速验证但效果比较简陋。真正做工具时建议加载一个指定字体文件。中文场景尤其要注意系统默认字体不一定支持中文可能会出现方框。最好明确指定一个字体文件路径比如 Windows 下的微软雅黑、macOS 下的 PingFang.ttc或者项目里放一个开源中文字体。4. 关键参数、输出格式和效果判断标准4.1 核心参数说明overlay 合成涉及的参数不算少重点是下面这一组。我把它们做成表格方便后面排查时对照。参数含义常见取值影响alpha叠加层整体透明度0 到 255常用 120 到 200越低越透明但太低会看不清内容坐标overlay 左上角位置根据底图尺寸动态计算位置偏移会导致元素出界或遮挡主体缩放比例overlay 尺寸相对底图宽度0.2 到 0.8太大遮主体太小没存在感混合模式像素融合算法normal / multiply / screen / overlay影响画面亮暗和颜色倾向边距overlay 到图片边缘的距离10 到 50 像素影响版式尤其保存后会生成不同裁切版本字体大小文字叠加层的大小按图片宽度比例计算不同分辨率下视觉一致性输出质量保存 JPG 的质量系数90 到 98太低会出现压缩伪影输出格式PNG 或 JPG透明内容用 PNG照片用 JPGPNG 体积大JPG 会丢失透明度每个参数都不是孤立的。比如缩小底图尺寸后如果 font 还是固定像素文字就会显得比原图大很多。坐标也是同样道理如果底图从 800x800 变成 4000x3000固定像素边距会让 overlay 看起来离边缘太近。推荐做法是边距、字体、缩放比例都以底图宽度为基准按比例计算。4.2 合成效果怎么判断很多初学者问“为什么我的 overlay 看起来怪怪的”但说不清哪里怪。我一般会从四个方面检查。第一个是透明区域的边缘。如果文字或图标边缘出现明显白色描边、黑色描边或锯齿优先检查 overlay 图片本身是否带 alpha以及 paste 时是否传了 mask。如果边缘是灰蒙蒙的也可能是 overlay 图片被缩放时没有使用高质量重采样滤镜导致抗锯齿效果变差。第二个是底图在透明区域的透过情况。正常的半透明叠加应该能隐约看到底图细节。如果 overlay 区域完全看不到底图说明 alpha 数值太高或不透明。如果几乎看不出 overlay 内容说明 alpha 太低。判断标准很简单缩放预览一下如果重叠区域里 overlay 内容还能清晰透出来底图也还能看到轮廓这个透明度就基本合理。第三个是整体亮度变化。如果你用了 multiply 或 screen 混合模式叠加区域的亮度会和 normal 模式完全不同。multiply 会让整体变暗screen 会让整体变亮。如果这不是你预期的效果就不要用复杂混合模式先切回 normal。第四个是坐标是否对齐。这个最直接看 overlay 元素是否超出画面、是否压住主体、是否和预期边距一致。如果只有某个角度看起来对齐旋转后就不对齐问题一般出在图片 EXIF 方向处理上。很多手机照片自带旋转方向信息读取图片后需要先根据 EXIF 旋转到实际显示方向再计算坐标。4.3 成功和失败的标准样例为了让自己快速验证 overlay 模块我建议固定一个最小测试集。一张亮色图片、一张暗色图片、一张包含人脸或主体的图片、一张竖拍图片。然后永远用同一套 overlay 代码测试。如果四张图的输出都满足下面几个条件这个模块就算基本稳定overlay 内容位置符合预期没有出界。透明区域能看到底图文字或图标边缘清楚。保存后没有黑边、白边、色偏。同一套参数在不同分辨率下视觉比例基本一致。反过来只要一张图出问题就能帮我缩小排查范围。比如只有竖拍图出问题优先查 EXIF 旋转。只有暗色图上的水印看不出来优先查 alpha 和混合模式。只有放大后边缘模糊优先查缩放滤镜。5. 常见报错和排查顺序5.1 输出全黑或全透明输出全黑最可能的情况是底图或 overlay 在转换格式时出了问题。比如底图是 CMYK 的 JPG直接用 Pillow 打开后某些操作会把颜色弄丢。先试试先把底图转成 RGB 再转 RGBA。输出全透明的场景更多出现在保存最终结果为 PNG 时。如果中间图层全部透明底图可能没有粘贴上去。检查一下代码顺序确保底图已经被写入输出图片而不是一直把透明画布当成最终结果。还有一种情况是 alpha 全为 0。比如创建透明画布时填充颜色写成了 (0, 0, 0, 0)这是没问题的。但如果你把一个不透明图层粘贴到透明画布时忘了传 mask可能得到一个黑色矩形粘贴后看起来像全黑。按前面说的所有要透明叠加的图层在 paste 时都必须把自身作为 mask 传进去。5.2 叠加后背景颜色变了背景颜色变化最常见原因是颜色空间或混合模式问题。先看是否使用了非 normal 混合模式。如果你手动修改过混合模式可以改回来测试。另一个原因是底图或 overlay 从 RGBA 转 RGB 时颜色空间没有处理一致。不同图像库对色彩配置文件的处理方式不同Pillow 打开带色彩配置文件的图片时转成 RGBA 再保存可能会有轻微色偏。这个问题在普通照片上不太明显但如果你做的是设计稿、截图或带有精确品牌色的图片就会很敏感。解决办法是如果对颜色要求很高不要频繁转换模式。读取后先统一转换一次合成完成后再转换一次输出。避免在合成过程中反复转 RGB、RGBA。另外避免在低质量quality 小于 85的 JPG 上叠加需要精确颜色的内容压缩会直接改变像素值。如果叠加层本身颜色和预期不一致先单独打开 overlay 原图确认它的颜色。很多 PNG 的颜色在预览工具里看起来很合适但粘贴后会受 alpha 混合影响。半透明叠加会把底图颜色透过来所以单看 overlay 原图颜色不能作为最终效果标准必须看合成结果。5.3 批量任务内存溢出、命名混乱和失败重试批量处理是很容易翻车的地方。直接遍历一万张图每张都 open 进去、合成、save看起来没什么问题但实际跑起来可能内存不断上涨。我常用的做法是每个任务在循环里用完图片就关闭或保持引用计数归零。Pillow 的 open 是惰性加载但 save 后会缓存一些信息。如果内存持续增长可以每隔若干张调用一次 gc.collect()或者改用 with 语句确保文件句柄正确释放。批量命名要提前规划。比如输出文件名带原始文件名加后缀又带时间戳。如果只用一个全局递增数字很容易和原图失去对应关系。建议用原文件名作为基础再追加 overlay 类型例如 photo_001_watermark.jpg。如果原文件名本身重复再在前面加日期或批次号。失败重试是我建议不要跳过的环节。批量处理 1000 张图片只要有一张图片损坏或格式异常整个流程就可能中断。更稳妥的做法是先遍历输入文件捕获打开异常。对每张图片单独 try/except。失败时把文件路径写入 error.log。最后统一处理 error.log 里的文件。这样不会因为一个坏文件丢掉全部结果。排查问题时先看 error.log再根据异常类型判断是格式、权限还是资源问题。5.4 有关联记忆的排查顺序如果你遇到 overlay 相关的问题我建议不要一上来就搜代码片段按下面顺序排查先看输出现象。是全黑、错位、变色、卡顿还是没反应。不同现象对应完全不同的原因。再确认输入图片本身。打开原图看是不是损坏、是不是有 EXIF 旋转、是不是双色模式或 CMYK。然后查出 overlay 图片的 alpha 通道。用图像查看软件打开确认透明区域真的是透明的。接着检查合成代码里的坐标、尺寸、mask 参数。最后考虑环境版本。Python、Pillow、OpenCV 升级后可能带来行为变化尤其是字体渲染和 Image.resize 的默认参数。很多时候看起来像 overlay 功能不支持的问题到第三步就解决了。因为 overlay 图片本身没有 alpha这是新手最容易踩的坑。6. 边界建议和进阶方向6.1 低配置环境怎么跑如果你是在普通笔记本或旧的手机上做 overlay 测试不用追求高分辨率合成。先跑 640x480 的小图确认逻辑正确再用原图尺寸跑单张最后才跑批量。这样可以快速判断是性能问题还是代码问题。低配环境下最需要优化的是大图缩放和实时预览。图片缩放很消耗内存一次性把 4000 万像素的手机照片加载进内存再创建一个同等大小的 RGBA 图层内存很容易冲到几百 MB。建议先查看原始图片的尺寸如果超过目标尺寸太多先缩放到目标范围再做 overlay。例如你只需要输出 1920 宽的照片就没必要把原图 4000px 的完整数据一层层叠加最后再缩小。这样做又慢又费内存。实时相机预览里更不要每帧都创建一个和预览分辨率一样的 overlay 位图。应该复用一个图层对象只更新位置和文本内容。如果处理速度还是不够可以降低预览分辨率比如先把 1080P 帧缩小到 720P再叠加 UI 内容。6.2 从单张到批量到实时相机的升级路径我建议把 overlay 项目分成三个阶段来做不要一次性想得太复杂。第一阶段只做单张图片合成。把底图读取、overlay 缩放、位置计算、透明度混合、输出保存全部跑通。这个阶段不需要关注速度只追求结果正确。第二阶段做批量处理。加入文件遍历、输出命名、错误日志、失败重试。这个阶段重点考察稳定性和可重复性。跑 100 张图都能通过再跑 1000 张。第三阶段才考虑实时相机预览。这时需要引入摄像头读取每帧绘制 overlay并且保证延迟可接受。从代码结构上最好把“单张合成”和“实时合成”拆成两个模块共用一个 overlay 配置类。实时模块负责性能优化单张模块负责高质量输出两者不要混在一起。这个顺序我强烈建议遵守。很多项目一上来就想做实时相机效果结果 overlay 位置还没调对就忙着处理帧率和内存最后两边都没做好。6.3 我建议的工具组合如果你主要做普通静态图片Pillow 加 OpenCV 已经足够。Pillow 负责加载保存和基本合成OpenCV 负责处理视频帧和图像变换。如果你的 overlay 内容非常复杂比如带实时动画、粒子效果、AR 标记可以考虑用专业的图形渲染框架例如 Shader 里的叠加纹理。但这些属于进阶内容不是普通 overlay 项目必须的。如果你做前端Canvas 2D 的 globalCompositeOperation 是处理混合模式的关键。CSS 里的 position: absolute 结合 opacity、mix-blend-mode 也能做简单的 overlay 展示但导出生图时还是要靠 Canvas。如果你做移动端 AndroidBitmap 的 Canvas.drawBitmap 配合 Paint 的 setAlpha、setXfermode 就可以实现透明叠加。iOS 方面CoreGraphics 的 CGContextDrawImage 加上 blendMode 也能完成类似操作。原理和 Python 代码里是一致的有底图、有 overlay、有 alpha 通道、有坐标、有混合方式。最后留几个我自己排查时会优先看的点先看 overlay 图片本身是否带 alpha再看坐标是不是按照旋转后的图片方向计算然后看是否用了正确的混合模式最后看批量处理时有没有统一命名和失败重试。把这几个点想清楚overlay 这个功能基本就能稳定落地了。