PPT批量换字体实战：基于OOXML的Python全量替换方案

做PPT的人都知道，字体这件事看着不起眼，真要统一改起来能让人崩溃。我最近接到一个需求：公司资料库里有几百个历史PPT，要把里面的“宋体”全部替换成“微软雅黑”，字号、颜色、加粗这些格式一律不能动。手工打开一个个改？先不说要多久，漏改一页、误改一处基本是必然。那段时间我花了不少精力研究PPTX的文件结构，最终写了一套批量字体替换脚本，跑一遍就能生成一份替换报告。这篇文章就把整个原理和落地过程完整还原一遍，从OOXML结构到代码实现，再到各种“替换了但没完全替换”的坑，全部摊开讲。

如果你手头也遇到PPT批量换字体、统一品牌视觉、或者给旧课件/旧报告做字体迁移的需求，这篇文章应该能帮你少走很多弯路。我会按照普通PPT文件最常见的场景来写，适用于Windows和macOS都能跑的Python方案。

1. PPTX的底层结构：为什么替换字体要先理解OOXML

1.1 PPTX不是“一个文件”，而是一个压缩包

很多人以为PPTX就是一个普通的二进制文档，实际上它本质是一个ZIP压缩包，里面住着一整套XML文件。不信你可以试一下：把一个PPTX后缀改成.zip，用解压工具打开，会看到一个类似这样的目录结构：

code复制sample.pptx
├── [Content_Types].xml
├── _rels/
├── docProps/
│   ├── app.xml
│   ├── core.xml
│   └── thumbnail.jpeg
└── ppt/
    ├── presentation.xml
    ├── presProps.xml
    ├── viewProps.xml
    ├── theme/
    │   └── theme1.xml
    ├── slideMasters/
    │   ├── slideMaster1.xml
    │   └── slideMaster2.xml
    ├── slideLayouts/
    │   ├── slideLayout1.xml
    │   ├── slideLayout2.xml
    │   └── ...
    └── slides/
        ├── slide1.xml
        ├── slide2.xml
        └── ...

这个结构是Open Packaging Conventions（OPC）规范的体现，PPtX脱胎于ECMA-376标准里的Office Open XML。我的建议是：在做任何批量修改PPT的操作之前，先亲手解压一个PPTX看看里面的XML。你一旦理解了“PPTX就是一堆XML文件被打包成一个zip”，后面的批量字体替换就变成了一件非常单纯的事情：找到XML里的字体声明，把旧字体名换成新字体名，重新打包，完事。

1.2 字体信息到底存在哪里：rPr、latin/ea/cs与主题字体

在PPTX的XML里面，一段带文字的形状大致长这样：

xml复制<p:sp>
  <p:txBody>
    <a:p>
      <a:r>
        <a:rPr lang="zh-CN" sz="1800" b="1" dirty="0">
          <a:latin typeface="宋体"/>
          <a:ea typeface="宋体"/>
          <a:cs typeface="宋体"/>
        </a:rPr>
        <a:t>这是一段示例文本</a:t>
      </a:r>
    </a:p>
  </a:txBody>
</p:sp>

要注意的是，a:rPr里有三个和字体相关的子节点，它们的分工完全不同：

• a:latin：西文字体（包含数字、英文字母）
• a:ea：East Asian字体，也就是中文、日文、韩文等东亚字符的字体
• a:cs：复杂文种字体（阿拉伯文、希伯来文等）

这个设计坑过很多人。常见的一种情况是：你通过代码或者手动操作，把a:latin的typeface改成了“微软雅黑”，打开PPT一看，中文没变，英文字母变了。原因就是中文走的是a:ea，你根本没碰到它。后面我会专门针对这个问题写一节排错指南。

字体信息还有一个藏身处：主题文件。ppt/theme/theme1.xml里定义了<a:fontScheme>，其中有两组字体：

xml复制<a:fontScheme name="我的主题">
  <a:majorFont>
    <a:latin typeface="等线 Light"/>
    <a:ea typeface="宋体"/>
  </a:majorFont>
  <a:minorFont>
    <a:latin typeface="等线"/>
    <a:ea typeface="宋体"/>
  </a:minorFont>
</a:fontScheme>

majorFont对应标题字体，minorFont对应正文字体。如果你在PowerPoint里不手动指定某个形状的字体，它就默认继承主题里的这两套字体。所以批量换字体实际上有两条路：第一，逐形状修改rPr；第二，修改主题的majorFont和minorFont。两条路各有优劣，我会在第3节讲实现，第4节讲隐藏字体信息的角落。

2. 换字体方案的取舍：python-pptx、直接改XML还是COM自动化

2.1 三种主流方案对比

理论上，批量修改PPTX字体的技术路线有很多，但真正在实际生产环境里能稳定落地的，我认为只有下面这三种。

先别急着选。这三条路线不是互斥的，我的建议是：以python-pptx为主力，以直接改XML为兜底，COM自动化只在需要处理特别复杂的文件时才考虑。

python-pptx的最大价值在于它是站在“形状模型”的角度来操作PPT，不用关心底层XML细节。比如你拿到一个幻灯片里的所有文本框，遍历它的段落和run，使用font.name和font.size等属性，就能完成80%的普通换字工作。但它有一个明显的边界：SmartArt图形里的文字、图表里的数据标签和图例文字、公式区域等，都不在常规的shape.text_frame遍历范围里。遇到这些内容，python-pptx会安静地“看不见”，替换报告里它们依然是零修改，但Presentation的XML里明明有旧字体。

这时候“直接操作XML”的价值就体现出来了。它的思路是：把PPTX当作zip包解压到临时目录，用正则或XML解析库扫描所有slides/*.xml、slideMasters/*.xml、slideLayouts/*.xml、theme/*.xml，找到所有typeface="旧字体名"的节点，批量替换成新字体名，再重新打包成PPTX。这个方案的覆盖面是最广的，因为不管你是普通形状、SmartArt还是图表，最终在XML层面都是同样的typeface属性。

2.2 我的选型结论与适用场景

这套选型逻辑不是理论推演，是踩了无数次坑之后总结出的实际经验。

先说COM自动化。如果你只需要处理三个五个文件，或者文件里全是复杂SmartArt和嵌入对象，那么PowerPoint COM确实是最省心的——因为你调用的就是PowerPoint自己的引擎，它能识别你肉眼能看到的一切东西。但如果你要处理几百个文件，COM的痛点会非常明显：每启动一次PowerPoint都是秒级延迟，几百个文件跑下来可能要一两个小时；而且PowerPoint进程一旦挂掉，很容易卡死在你的脚本里，后面操作的文件全部失败。我见过不少人在这个小规模Demo里玩得很开心，一上生产就翻车。

直接改XML也有一个很大的风险：XML结构多复杂啊，命名空间前缀、各种可选节点、空节点、属性顺序，稍不留神就会改出一个PowerPoint打开就提示“已修复”的坏文件。所以成熟的方案应该是两者结合：

1. 优先用python-pptx遍历所有“常规形状”，处理文本框里能访问到的run；
2. 再用一个基于XML的“兜底替换器”，扫描整个解压目录里的所有typeface属性做全局替换；
3. 替换完成后用python-pptx重新打开一次文件做冒烟测试，确认文件没被改坏。

这个组合既能保证普通文字的高效处理，又能兜住那些python-pptx覆盖不到的隐藏字体，而且速度快、跨平台。后面第3节和第5节我都会给出可直接复用的代码。

3. 核心实现：从XML节点到批量替换的完整代码

3.1 用python-pptx搞定常规形状的文字

先来看最简单，也最符合大多数人直觉的实现。用python-pptx遍历每一张幻灯片，找到所有包含文字的shape，遍历paragraph和run，依次设置font.name。这个过程看起来毫无技术含量，但里面埋着一个大坑：中文。直接贴一段代码验证给你看：

python复制from pptx import Presentation
from pptx.util import Pt

SRC = "input.pptx"
DST = "output.pptx"

OLD_FONT = "宋体"
NEW_FONT = "微软雅黑"

prs = Presentation(SRC)
changed_count = 0

def iter_paragraphs(shape):
    if not shape.has_text_frame:
        return
    for para in shape.text_frame.paragraphs:
        yield para

for slide in prs.slides:
    for shape in slide.shapes:
        for para in iter_paragraphs(shape):
            for run in para.runs:
                if run.font.name == OLD_FONT:
                    # 这里只修改了latin字体，中文不会变
                    run.font.name = NEW_FONT
                    changed_count += 1

prs.save(DST)
print(f"changed {changed_count} runs")

这段代码跑完后，英文和数字会变成“微软雅黑”，中文仍然是“宋体”。为什么？因为run.font.name这个属性在底层映射到的是a:latin的typeface属性，它根本管不到a:ea。在python-pptx里你要同时修改东亚字体，就得直接操作run的XML。一个可行的写法是给run的rPr元素补充a:ea节点：

python复制from pptx.oxml.ns import qn

def set_font_of_run(run, old_font: str, new_font: str):
    """返回True表示有修改"""
    if run.font.name != old_font:
        return False

    run.font.name = new_font  # 修改 latin
    rPr = run._r.get_or_add_rPr()

    # 处理 a:ea
    ea = rPr.find(qn("a:ea"))
    if ea is None:
        ea = rPr.makeelement(qn("a:ea"), {})
        rPr.append(ea)
    ea.set("typeface", new_font)

    # 处理 a:cs，建议一并替换
    cs = rPr.find(qn("a:cs"))
    if cs is None:
        cs = rPr.makeelement(qn("a:cs"), {})
        rPr.append(cs)
    cs.set("typeface", new_font)

    return True

为什么要处理a:cs？因为在中文PPT里经常有数字、英文和中文混排的情况，而且很多输入法会把字符标记为复杂文种。你只改latin和ea，cs没动，某些场景下字符依然会以旧字体显示。最稳妥的做法是三个字体节点全部统一替换。

3.2 直接操作XML的通用替换器

python-pptx的覆盖范围有限，所以我们还需要一个更底层的“通用替换器”。核心思路很简单：把PPTX解压到临时目录，用re或lxml替换所有typeface属性里的旧字体名，然后再打包。

考虑到性能和稳妥性，我建议用正则配合字符串替换，而不是lxml重新序列化整个XML文件。因为lxml在解析和重新输出时，可能改变原本的属性顺序、命名空间前缀和缩进，虽然这些大多不影响功能，但会增加“打开已修复”的风险。字符串替换反而更安全，前提是你用足够严格的匹配模式。

python复制import re
import shutil
import zipfile
from pathlib import Path

def replace_typeface_in_xml(xml_text: str, old_font: str, new_font: str) -> str:
    # 匹配 typeface="宋体" / typeface='宋体' / typeface="宋体" 前面带空格
    pattern = re.compile(r'(typeface\s*=\s*["\'])(' + re.escape(old_font) + r')(["\'])')
    replaced_text, count = pattern.subn(lambda m: m.group(1) + new_font + m.group(3), xml_text)
    return replaced_text, count

def replace_font_in_pptx(pptx_path: Path, output_path: Path, old_font: str, new_font: str) -> int:
    tmp_dir = Path(pptx_path.parent) / f"_tmp_{pptx_path.stem}"
    if tmp_dir.exists():
        shutil.rmtree(tmp_dir)
    tmp_dir.mkdir()

    total = 0
    try:
        # 1. 解压
        with zipfile.ZipFile(pptx_path, 'r') as zf:
            zf.extractall(tmp_dir)

        # 2. 遍历所有 xml 文件进行替换
        for xml_file in tmp_dir.rglob("*.xml"):
            text = xml_file.read_text(encoding="utf-8")
            new_text, cnt = replace_typeface_in_xml(text, old_font, new_font)
            if cnt:
                xml_file.write_text(new_text, encoding="utf-8")
                total += cnt

        # 3. 重新打包
        with zipfile.ZipFile(output_path, 'w', zipfile.ZIP_DEFLATED) as zf:
            for file_path in sorted(tmp_dir.rglob("*")):
                if file_path.is_file():
                    arcname = file_path.relative_to(tmp_dir).as_posix()
                    zf.write(file_path, arcname)
    finally:
        shutil.rmtree(tmp_dir, ignore_errors=True)

    return total

这个“通用替换器”最关键的是两点：

• 它覆盖了ppt/slides/之外的文件，也就是母版、版式、主题、备注页、讲义页等所有XML；
• 它匹配的是属性值而不是标签，所以不会误伤<a:latin typeface="宋体"/>之外的其他属性值。

3.3 主题字体替换：一键换掉默认字体

如果你只想改掉“默认字体”，而不想挨个改每个形状，那么直接替换主题文件是最快的方式。比如把主题里所有majorFont和minorFont的字体都换成新字体：

python复制import re
from pathlib import Path

def replace_theme_fonts(pptx_path: Path, new_latin: str, new_ea: str, output_path: Path):
    import zipfile, shutil

    tmp_dir = Path(pptx_path.parent) / f"_theme_tmp_{pptx_path.stem}"
    if tmp_dir.exists():
        shutil.rmtree(tmp_dir)
    tmp_dir.mkdir()

    try:
        with zipfile.ZipFile(pptx_path, 'r') as zf:
            zf.extractall(tmp_dir)

        theme_files = list(tmp_dir.glob("ppt/theme/theme*.xml"))
        for theme_file in theme_files:
            xml_text = theme_file.read_text(encoding="utf-8")
            # 替换 <a:latin typeface="xxx"/> 中的 typeface 值
            xml_text = re.sub(
                r'(<a:latin\s+typeface=")[^"]*(")',
                lambda m: m.group(1) + new_latin + m.group(2),
                xml_text
            )
            xml_text = re.sub(
                r'(<a:ea\s+typeface=")[^"]*(")',
                lambda m: m.group(1) + new_ea + m.group(2),
                xml_text
            )
            theme_file.write_text(xml_text, encoding="utf-8")

        with zipfile.ZipFile(output_path, 'w', zipfile.ZIP_DEFLATED) as zf:
            for file_path in sorted(tmp_dir.rglob("*")):
                if file_path.is_file():
                    arcname = file_path.relative_to(tmp_dir).as_posix()
                    zf.write(file_path, arcname)
    finally:
        shutil.rmtree(tmp_dir, ignore_errors=True)

不过这里要注意：主题替换能改的是“没有直接设置字体”的那些文本。一旦某个形状或某个母版在XML里明确写了typeface，它就会覆盖主题设置。这也是为什么实际操作中，我都会先跑一遍“通用替换器”，把显式指定的旧字体替换掉，再跑主题字体替换，把默认字体也统一过来。

4. 隐藏字体信息的角落：母版、主题与占位符的联动

4.1 字体层级：主题 → 母版 → 版式 → 幻灯片

PPT字体的继承关系，非常像CSS的选择器优先级。简单地说，字体生效优先级从高到低是这样：

1. 幻灯片页面里的形状直接设置字体（run级别rPr）
2. 幻灯片版式（slideLayout）里设置的占位符字体
3. 幻灯片母版（slideMaster）里设置的占位符字体
4. 主题（theme）中定义的majorFont/minorFont

用一句话概括：越靠近具体文本的声明，越有话语权。这意味着你只改主题文件，能影响的范围其实很有限——所以做一个“全局替换器”时必须把所有XML都扫一遍，而不是只处理slides/里的XML。

我见过很诡异的一个案例：一份PPT里某个章节标题，肉眼看上去就是宋体，但python-pptx遍历时发现它的run.font.name是空的，也就是说这个run没有显式字体设置。后来解压发现，字体是在母版的<p:ph>占位符样式里指定的。这种情况如果你的脚本只扫slides/，就完全不会生效。最保险的做法，还是把所有XML文件丢进同一个替换器里处理，爱藏在哪藏在哪。

4.2 SmartArt、图表和表格里的字体

SmartArt图形在渲染前会被展开为<p:graphicFrame>里的<dgm:relIds>引用，字体相关的内容其实在slideX.xml里的<a:p>节点中，只是python-pptx的shape.text_frame不会返回它。同样，图表里的数据标签、轴刻度、图例，字体信息也在slideX.xml内的<c:txPr>、<c:rich>等节点。表格里的字体则在每个单元格的<a:txBody>。

由于这些节点在XML底层全部统一为<a:rPr>下的<a:latin>、<a:ea>、<a:cs>，所以第3.2节那个“通用替换器”才那么关键——它根本不关心你是什么图形对象，只认typeface属性。这也是我强烈建议不管用什么高级API，都要保留一个“直接扫描typeface属性”的兜底逻辑的原因。

还有一类更隐蔽的：Notes Slide（备注页）、Handout（讲义页），它们也有独立的XML文件，某些备注内容里如果嵌入了文字，同样带字体声明。通用替换器因为扫描的是*.xml，自然会把它们包含进来。

5. 批量工程化：文件扫描、并发处理与备份回滚

5.1 全量扫描与映射表设计

单个文件的替换搞定后，真正迈向“生产可用”，还需要解决三个问题：文件从哪来、怎么并发、改坏了怎么办。

先用一个JSON文件定义字体映射表。这里不能简单写死“宋体变微软雅黑”一条规则，因为同一份PPT里极可能出现“宋体”“SimSun”“宋体-简”等多种写法，文件来源不同，名字也可能不同。我把映射表设计成支持多个旧名对应一个新名：

json复制{
  "font_map": [
    {
      "old": ["宋体", "SimSun", "宋体-简", "NSimSun"],
      "new": "微软雅黑"
    },
    {
      "old": ["Times New Roman"],
      "new": "Arial"
    }
  ],
  "skip_list": [
    "Wingdings",
    "Symbol"
  ]
}

skip_list是防止把特殊符号字体也给换掉的。Wingdings和Symbol这类字体虽然长着“字体”的名字，实际是符号库，换了之后特殊图标全变方框。这个细节我建议一定要加进自己的脚本里。

5.2 多线程并发与独立临时目录

批量处理几百个文件时，单线程逐个解压、读XML、重新压缩，性能会非常难看。实测普通PPT文件单个大约需要0.5到1.5秒，几百个就是好几分钟。为了加快速度，我用了Python的ThreadPoolExecutor做并发，CPU密集部分主要是压缩，多核并发效果明显。

但并发有一个大坑：每个文件解压时都用到同一个临时目录名字会冲突。我之前就是图省事，给所有文件解压到同一个_tmp目录，结果多个线程互相删文件，跑出来的PPT全是坏的。正确的做法是给每个任务分配一个独立的临时目录，目录名带上线程ID或UUID，处理后立即清理：

python复制import uuid
from concurrent.futures import ThreadPoolExecutor, as_completed
from pathlib import Path
import shutil, zipfile, json, re

def process_one(pptx_path: Path, out_path: Path, font_map, skip_list):
    tmp_dir = Path(pptx_path.parent) / f"_tmp_{pptx_path.stem}_{uuid.uuid4().hex[:8]}"
    if tmp_dir.exists():
        shutil.rmtree(tmp_dir)
    tmp_dir.mkdir()
    try:
        with zipfile.ZipFile(pptx_path, 'r') as zf:
            zf.extractall(tmp_dir)

        for xml_file in tmp_dir.rglob("*.xml"):
            text = xml_file.read_text(encoding="utf-8")
            for rule in font_map:
                for old_font in rule["old"]:
                    if old_font in text:  # 快速过滤，避免无意义的正则
                        new_font = rule["new"]
                        if old_font in skip_list:
                            continue
                        text, _ = replace_typeface_in_xml(text, old_font, new_font)
            xml_file.write_text(text, encoding="utf-8")

        with zipfile.ZipFile(out_path, 'w', zipfile.ZIP_DEFLATED) as zf:
            for file_path in sorted(tmp_dir.rglob("*")):
                if file_path.is_file():
                    arcname = file_path.relative_to(tmp_dir).as_posix()
                    zf.write(file_path, arcname)
        return True, pptx_path.name, "OK"
    except Exception as exc:
        return False, pptx_path.name, str(exc)
    finally:
        shutil.rmtree(tmp_dir, ignore_errors=True)

def batch_replace(input_dir: Path, output_dir: Path, config: dict):
    output_dir.mkdir(parents=True, exist_ok=True)
    font_map = config["font_map"]
    skip_list = config.get("skip_list", [])
    tasks = []
    for pptx_path in input_dir.glob("*.pptx"):
        out_path = output_dir / pptx_path.name
        tasks.append((pptx_path, out_path))

    with ThreadPoolExecutor(max_workers=8) as executor:
        future_map = {
            executor.submit(process_one, p, o, font_map, skip_list): p
            for p, o in tasks
        }
        for future in as_completed(future_map):
            ok, name, msg = future.result()
            print(f"{name}: {'成功' if ok else '失败'} - {msg}")

5.3 备份与校验

文件替换是破坏性操作，再好的脚本也要做备份。我的做法是：批量处理前，把原始文件复制一份到input_backup_日期目录，不直接修改原目录里的文件，而是把结果输出到output_日期目录。等抽查确认无误后，才用输出目录覆盖原目录。

输出之后，不能只看替换日志完事，还要做两层校验：

• 用zipfile.ZipFile打开每个输出文件，调用testzip()检查是否有CRC错误；
• 再用python-pptx加载一次，确保PowerPoint能正常打开不报“已修复”。

python复制import zipfile
from pptx import Presentation

def verify_pptx(path: Path) -> bool:
    try:
        with zipfile.ZipFile(path, 'r') as zf:
            bad_file = zf.testzip()
            if bad_file:
                print(f"{path}: zip 校验失败 - {bad_file}")
                return False
        Presentation(str(path))
        return True
    except Exception as exc:
        print(f"{path}: 校验异常 - {exc}")
        return False

这套校验思路看起来简单，但真的能拦下很多问题。我第一次跑批量脚本时，就是因为太信任正则替换，结果有一个文件在解压时出现了中文路径编码问题，打包后PPT直接打不开。加了testzip和Presentation()双重验证以后，所有坏文件在交付之前就能被发现。

6. 踩坑实录：替换后字体不生效的六种原因

6.1 只改了latin没改ea，中文纹丝不动

这个问题我在第1节、第3节都反复强调过。它的本质是a:latin管西文、a:ea管中文，PowerPoint解析时对中文文本只会去看a:ea。替换脚本如果只替换了a:latin，数字和英文变了，中文一点变化都没有，你会以为脚本失效了。解决办法就算改成run.font.name也不能只改latin，要手动操作XML把a:ea一并处理。这个坑占据了我整个项目遇到的问题里将近一半。

6.2 形状直接指定了字体，主题替换“看不见”

如果你只改了主题文件里的majorFont和minorFont，运行后发现大部分文本都换过来了，但部分文本框纹丝不动，多半是这些文本框在源文件里被手动指定过字体。你可以打开PPT，选中文本看字体下拉框是不是有具体的“宋体”而不是“（默认）宋体”。有具体字体声明的地方，主题替换管不到，必须靠“通用替换器”去扫描typeface。

6.3 SmartArt、图表和公式不在常规遍历范围内

python-pptx能直接访问的是shape里面的text_frame，但SmartArt图形是graphicFrame，图表是graphicFrame里的<c:chart>引用，公式直接被渲染成图片或者OLE对象。这些都是API盲区。遇到复杂PPT，不要指望单靠python-pptx能解决，直接用“通用替换器”扫描底层的typeface才是根本方案。

6.4 字体名写错：微软雅黑 vs Microsoft YaHei

另一个非常容易翻车的是字体名写法。PPTX的XML里，typeface的值可以是中文名“宋体”，也可以是英文名“SimSun”，具体取决于源文件的字体选择。替换脚本如果要匹配“宋体”，但文件里存的是“SimSun”，它就替换不到。所以映射表里必须同时列出一个字体的多个别名，至少要把中文名、英文都放进去。“微软雅黑”对应的是“Microsoft YaHei”，“黑体”对应“SimHei”或“SimHei”。这个规则如果你自己整理一次，能避免大量无意义的失败调整。

6.5 重新打包后提示“已修复”的XML小问题

如果你直接用字符串替换法，而替换时不小心改坏了XML结构，PowerPoint打开时会弹“已修复的部分”。常见的作死操作包括：替换时用text.replace("宋体", "微软雅黑")不加引号，结果把路径或者命名空间里包含“宋体”的部分也给改了；或者把typeface替换成空字符串，留下一个typeface=""的非法属性。我解决这个问题的经验是：但凡用字符串正则替换，必须保证替换前后XML仍然能被标准XML解析器正常解析，最好在替换后跑一次xmllint --noout或Python的xml.dom.minidom.parse做语法校验。

6.6 并发写共享文件导致Zip损坏

多线程处理时，如果不同线程访问了同一个临时目录、或者同一个输出路径，就会出现zip文件损坏。这个问题往往不是每次必现，而是间歇性出现，排查起来特别头疼。我的教训是：临时目录必须带unique标识，输出路径也必须确保不重名，最好在提交任务之前就把所有输出路径统一算好。

用这套方案跑通一个真实案例之后，我留下几个习惯

现在这套流程已经沉淀成团队内部的统一工具。每次拿到新的PPT批量处理需求，我不会上来就写代码，而是先随机挑三五个不同来源的PPT解压，人工看一眼它们的字体声明分布，确认是集中在slides/还是也散落在theme/和slideMasters/里。这个“先侦察再动手”的步骤，让我省掉了大量反复调试的时间。

我个人还坚持做一件看起来有点笨的事：每次批量替换前，先跑一次dry-run模式，只统计每个文件里有多少处旧字体会被替换，不真正写入。生成一份报告后，我扫一眼各文件的替换数量是否有异常——如果某个文件字体替换量为0，但其它文件都是几百，那它大概率是特殊结构，需要单独人工检查。这个习惯帮我发现了不少藏在角落里的问题。

最后提醒一下，字体替换不只是“把名字换掉”这么简单。中文字体替换时，一定要确认新版字体覆盖了你需要的字形范围，像某些异体字、生僻字，在老字体里能显示，新字体里可能变成豆腐块。批量替换完成后，抽一页来人工目检，永远比代码校验更可靠。希望这套方法能帮你稳妥搞定PPTX批量字体替换，省下来的时间，足够好好休息一晚。