根本原因是Excel进程未真正退出或COM对象残留导致文件句柄被锁；需显式按顺序释放COM对象、避免可见模式、禁用WPS干扰，并验证EXCEL.EXE是否彻底消失及文件能否重命名。
根本原因几乎总是Excel进程没真正退出，或者COM对象残留导致文件句柄被锁住——不是Python代码没保存，而是Windows底层资源没释放。
xlwings 或 win32com 操作后 Excel 进程仍在后台运行
调用 xlwings.App() 或 win32.Dispatch('Excel.Application') 后，即使你调用了 wb.close() 和 app.quit()，Excel进程（EXCEL.EXE）仍可能卡在任务管理器里。Windows COM机制不会自动回收进程，尤其当异常中断、未显式释放 COM 对象或存在隐藏弹窗（如“是否保存更改”提示）时。
- 检查任务管理器 → 详细信息 → 查找
EXCEL.EXE，手动结束它再试 - 强制退出写法（带超时和异常兜底）：
try: app.quit() except: pass import os os.system('taskkill /f /im EXCEL.EXE 2>nul') - 避免使用
app.visible = True：可见模式下用户交互会阻塞退出逻辑
openpyxl 或 pandas 写入后文件被独占锁定
openpyxl.load_workbook() 默认以读写模式打开，哪怕你只读也申请排他访问；pandas.to_excel() 在保存时若目标文件正被其他程序（包括WPS预览窗格、OneDrive同步进程、甚至资源管理器缩略图生成器）打开，就会触发 [WinError 32]。
- 纯读取场景改用
load_workbook(filename, read_only=True)，不申请写锁 - 写入时别直接覆盖原文件：
df.to_excel('temp.xlsx'); os.replace('temp.xlsx', 'report.xlsx') - 用 PowerShell 快速查谁在占用：
Get-Process | Where-Object { $_.Modules.FileName -like "*report.xlsx*" } - 关掉 Windows 资源管理器的“预览窗格”——这是静默锁文件的高频元凶
WPS 与 Office 共存引发 COM 类型库冲突
WPS 安装时会篡改注册表中 Excel 的 COM 接口映射（如把 {00020813-...} 指向 WPS 组件），导致 win32.Dispatch('Excel.Application') 实际调起 WPS 引擎，但 WPS 不完全兼容 Office 的 COM 方法（比如缺少 Workbooks.Open），后续文件操作失败或句柄异常泄漏。
立即学习“Python免费学习笔记（深入）”；
- 临时绕过：改用
xlwings.Book(app_visible=False)，它会尝试跳过注册表直连 - 根治方案：进注册表
HKEY_CLASSES_ROOT\Interface\{000208**-}\TypeLib，把被 WPS 改掉的值手动还原为 Office 的 CLSID 和 Version - 开发机建议卸载 WPS，或至少禁用其“兼容 Microsoft Office”选项
最常被忽略的是：你以为脚本跑完了，其实 Excel 进程还挂着；你以为文件保存成功了，其实只是磁盘写入完成，而操作系统层面的文件锁还没释放。处理完务必验证 EXCEL.EXE 是否彻底消失，且用 os.rename() 尝试重命名目标文件——能重命名才说明真正解锁了。
