根本原因是 php 库不解析 pptx 视觉渲染层，图片特效（阴影、发光等）存于 p:sppr 和 p:blipfill 的 xml 属性中，而 phppresentation 等库仅处理基础结构，不读取也不透传这些节点。
PHP 读写 PPTX 文件时图片特效丢失的根本原因 PHP 本身不解析 PPTX 的视觉渲染层，PhpPresentation 或 PHPPresentation 这类库只处理基础结构（幻灯片、文本框、形状），而图片的「特效」——比如阴影、柔化边缘、发光、3D 旋转、剪裁蒙版——全存在 p:spPr 和 p:blipFill 下的复杂 XML 属性里，这些库默认不读取、更不会原样透传。你用 addImage() 加进去的图，只会走最简路径，特效自然归零。
常见错误现象：PhpPresentation 加载原 PPTX 后调用 save()，再打开发现所有图片变“平”了：没阴影、没圆角裁切、甚至位置偏移；或者直接报错 DOMDocument::loadXML(): Empty string supplied —— 那是它在跳过不认识的特效节点时破坏了 XML 结构。
用 ZipArchive 直接操作 PPTX 内部 XML（唯一可靠方案）PPTX 本质是 ZIP 包，图片特效定义在每张幻灯片的 slideN.xml 里（路径类似 ppt/slides/slide1.xml），藏在 <pic></pic> 节点下的 <sppr></sppr> 子树中。想保留，就得绕过高层库，自己解压、定位、修补、重压。
实操建议：
- 用
ZipArchive::open()打开原 PPTX，getFromName()提取目标slide1.xml - 用
simplexml_load_string()解析 XML，注意加SIMPLEXML_LOAD_STRING_DEFAULT选项避免命名空间干扰 - 定位到
//p:pic[p:nvPicPr/p:cNvPr[@name="your_image_name"]]（靠图片 name 或 embed rId 匹配） - 把原
<sppr>……</sppr>整块复制过去，不要只抄<blip></blip> - 修改完用
asXML()写回 ZIP，最后close()
性能影响：比用 PhpPresentation 慢 3–5 倍，但这是保特效的唯一路径。兼容性上，Office 2013+ 和 LibreOffice 7.4+ 都能正确渲染，旧版可能忽略部分属性但至少不报错。
PhpPresentation 中添加新图片时如何最小化特效损失 它不支持写特效，但可以“借壳”：先在 PowerPoint 里建一个带所需特效的空白图片占位符，保存为模板 PPTX，然后 PHP 只替换该占位符的底层 <blip></blip> 的 r:embed 值和对应 media/ 里的文件。
关键步骤：
- 模板里图片必须设好所有特效，并在「设置图片格式」→「大小与属性」→「名称」里手动填个唯一名（如
hero_banner_effect），方便 XML 定位 - PHP 中用
ZipArchive替换ppt/embeddings/下的image1.jpeg，同时更新slide1.xml里匹配该名的<embed></embed>ID - 别动
<sppr></sppr>任何子节点，连空格都别增删——PowerPoint 对 XML 格式敏感
容易踩的坑：PhpPresentation 的 addImage() 会自动生成新 rId，但模板里旧 rId 是硬编码在 <blipfill></blipfill> 里的，ID 不一致就显示“图片不可用”。
为什么不能用 COM 或 OpenOffice 自动化替代？Windows 上用 PHP 调 com_dotnet 加载 PowerPoint COM 对象确实能保留全部特效，但要求服务器装桌面版 Office、开启交互式桌面会话、且并发一高就卡死或崩溃；Linux 下用 LibreOffice headless 转换，soffice --convert-to pptx 会彻底丢弃特效并重排版。两者都违背「服务端稳定批量处理」的前提。
真正要保留特效，只有直捣 XML 这一条路。复杂点在于：每种特效对应不同 XML 路径（发光在 <effectlst></effectlst>，柔化在 <scene3d></scene3d>），改错一层就整张图失效。没人帮你校验，得自己对着原始 slide1.xml 逐行比对。
