用C++和COM接口实现iTunes自动化：从环境搭建到实战避坑

简介：这是一份面向C++开发者的完整iTunes功能实现示例，聚焦模拟登录与礼品卡兑换两大核心流程。项目基于Visual Studio构建，共18个文件，包含main.cpp源码、curl.h等9个头文件、sln与vcxproj工程配置、编译生成的exe以及libcurl库文件，压缩包仅1.85MB，结构紧凑、目录清晰，便于快速上手。代码借助libcurl完成HTTP/HTTPS通信，在登录环节处理用户名与密码的封装和传输，在兑换环节实现礼品卡有效性、金额及使用状态的多重校验，并更新账户余额；同时展示JSON数据解析与网络断开等异常场景的容错写法，适合需要掌握C++网络编程或参考客户端API交互实战的开发者。目前已有666人学习下载，内含可直接编译运行的完整工程，可帮助读者快速理解iTunes类服务对接的代码组织方式、第三方库引入与依赖管理方法。

1. iTunes功能示例完整C++代码要解决什么问题：把媒体库操作变成自动化

给某个歌手整理几十场歌单，要从几百首曲目里筛出指定艺人的歌并生成播放列表；想在自己写的桌面工具里嵌入一个“下一首”按钮；想在凌晨自动按播放次数重新排序歌单——这些事手动点iTunes点到手酸，而且重复性极高。iTunes功能示例完整C++代码做的就是这个：通过COM接口，把iTunes暴露出来的媒体库对象一个个接住，用C++读取曲目信息、控制播放、创建播放列表、导出歌单数据。对Windows上做桌面工具或多媒体自动化的开发者来说，这是一条比模拟鼠标点击稳得多的路，接口语义固定，返回结构清晰。新手照着示例能快速跑通第一条链路，熟手也能从这里摸到跨进程COM调用的边界和坑。

2. 搭起能跑的环境：iTunes的COM接口与C++连接最小方案

2.1 为什么C++选COM接口：iTunes对外只有这一条自动化通道

iTunes的媒体库、播放列表、播放器状态都在它自己的进程里，C++程序进不去那个内存空间。官方对外开放的自动化入口是一组COM接口，注册的ProgID是“iTunes.Application”。C++通过COM运行时创建它的实例，拿到根接口指针后，后续所有媒体库操作本质上都是跨进程调用。每次属性读取都会经过RPC转发到iTunes进程再返回结果，速度比进程内调用慢几个量级，但胜在稳定、语义清晰，没有窗口句柄、模拟按键那套玄学。

iTunes的COM对象模型不复杂，记熟下面这张表就够用了：根对象是iTunesApp，整个资料库其实只是它下面的一个特殊播放列表叫LibraryPlaylist，播放列表各自挂着曲目集合，集合里每个元素是一首曲目。后面所有示例都是顺着这条链往下摸。

这里有两个隐含行为需要先记住：第一次创建iTunes实例时，如果iTunes没有运行，COM会自动把它启动起来，所以首次调用会明显偏慢；反过来，如果用户手动把iTunes退出了，程序里缓存的代理指针再调用时会报“对象已断开”一类的错误。这两个行为在第五章避坑里还会展开，先知道它们存在即可。

2.2 最小环境配置：#import类型库与工程设置

在Visual Studio里编译，最省事的方式是用#import指令直接读iTunes的类型库。#import会让编译器生成tlh和tli两个头文件，里面包含所有接口定义、智能指针类型和枚举常量。类型库可以从iTunes主程序里抽取，只要路径指向安装目录即可。下面是工程开头最常见的写法：

#import "iTunesLib.tlb" named_guids no_namespace #include <atlbase.h> #include <atlcom.h>

named_guids让编译器生成CLSID_iTunesApp等GUID常量，方便后面用CreateInstance直接创建；no_namespace把智能指针类型直接暴露到当前命名空间，省去每个类型前写iTunesLib::前缀的麻烦。ATL头文件是系统SDK自带的，不用额外配置库目录。这个组合是社区里最常见的配置，稳定性足够。

工程属性里还要做两件事：第一，“字符集”选“使用Unicode字符集”，因为COM接口返回的字符串全是宽字符BSTR，项目用多字节字符集后面会遇到一堆乱码；第二，平台位数直接选x86，原因放在第五章展开，这里先记住结论。建一个空的控制台工程就够了，不需要MFC或ATL向导，避免引入额外依赖。

2.3 初始化COM并与iTunes建立连接：最小可跑代码

下面是连接iTunes的最小代码，核心就三步：初始化COM、创建iTunes实例、验证连接。这段代码可以直接放进main里跑，能看到媒体库曲目数就说明链路通了。

#include <windows.h> #include <atlbase.h> #import "iTunesLib.tlb" named_guids no_namespace bool ConnectToITunes(IITiTunesPtr& spITunes) { // 初始化COM：用多线程套间，避免绑定UI线程的消息循环 HRESULT hr = CoInitializeEx(NULL, COINIT_MULTITHREADED); if (FAILED(hr) && hr != RPC_E_CHANGED_MODE) { wprintf(L"CoInitializeEx failed: 0x%08X\n", hr); return false; } // 按ProgID创建iTunes COM对象；若iTunes未运行会自动拉起进程 hr = spITunes.CreateInstance("iTunes.Application"); if (FAILED(hr)) { wprintf(L"CreateInstance failed: 0x%08X\n", hr); wprintf(L"请确认已安装iTunes，且本程序没有以管理员权限运行\n"); return false; } // 读取媒体库曲目数，验证连接真实可用 IITLibraryPlaylistPtr spLib = spITunes->LibraryPlaylist; long count = spLib->Tracks->Count; wprintf(L"iTunes 已连接，媒体库共 %d 首曲目\n", count); return true; }

CoInitializeEx的两个参数：第一个是保留值传NULL，第二个是套间模式。用COINIT_MULTITHREADED让线程进入多线程套间（MTA），适合在工作线程里跑批量读取；如果程序有UI并且要接收COM事件，才考虑COINIT_APARTMENTTHREADED加消息循环。RPC_E_CHANGED_MODE表示当前线程已经被初始化成其他套间模式，这不影响后续调用，所以不能直接判失败。

CreateInstance("iTunes.Application")内部通过ProgID找到CLSID再创建实例，比直接写CLSID更直观，也给后期排查留了余地。需要提醒的是，如果本程序以管理员权限运行，而iTunes以普通用户权限运行，跨进程COM的权限校验可能会失败，表现为CO_E_RUNAS_LOGON_FAILURE一类错误。

2.4 智能指针与COM生命周期：释放顺序别乱

用#import生成的智能指针（IITiTunesPtr、IITTrackPtr等）是_com_ptr_t的实例，析构时自动调Release，所以常规代码不需要手写Release。但跨进程COM的释放顺序有讲究：先释放从根对象取出来的叶子接口，再释放根对象指针。原因是代理对象在释放时会向远端发送请求，如果根对象先释放，叶子指针的释放可能触发异常。

void Cleanup(IITiTunesPtr& spITunes) { // 先让智能指针置空，触发叶子接口Release // 实际代码中通常是作用域退出自动析构，这里演示显式清理 spITunes = nullptr; // 释放根对象代理 CoUninitialize(); // 与CoInitializeEx成对 }

CoUninitialize要和CoInitializeEx成对调用，且尽量不要写在DLL的入口函数里，否则可能随进程卸载顺序出现死锁。我的习惯是只在main或工作线程的收尾处调用。还有一个细节：智能指针重试赋新值时，旧值会被自动释放，所以spITunes = nullptr这行是安全的，不用先手动Release。

3. 完整C++示例：读取媒体库、筛选歌单与控制播放

3.1 枚举媒体库全部曲目并打印关键属性

拿到媒体库曲目集合后，第一件常做的事就是把全部曲目扫一遍。需要注意集合索引从1开始，不是0，而且删除过曲目后集合里可能留下空槽，所以每次取值都要判空。

void PrintAllTracks(IITiTunesPtr& spITunes) { IITLibraryPlaylistPtr spLib = spITunes->LibraryPlaylist; IITTrackCollectionPtr spTracks = spLib->Tracks; long nCount = spTracks->Count; for (long i = 1; i <= nCount; ++i) { IITTrackPtr spTrack = spTracks->Item[i]; if (spTrack == nullptr) continue; // 删除过的槽位可能为空 _bstr_t bName = spTrack->Name; _bstr_t bArtist = spTrack->Artist; _bstr_t bAlbum = spTrack->Album; long nPlay = spTrack->PlayCount; wprintf(L"%5d | %s | %s | %s | 播放%d次\n", i, (wchar_t*)bName, (wchar_t*)bArtist, (wchar_t*)bAlbum, nPlay); } }

这段代码里_bstr_t是BSTR的封装类，能自动管理内存，转成wchar_t*后直接传给wprintf的%s格式符。PlayCount是只读属性，表示这首曲目在iTunes里累计播放的次数，做排序歌单时常用。整个循环本质是几千次跨进程调用，如果媒体库很大，耗时可能会吓到你——这就是后面避坑章里“界面卡死”那条的根源。

3.2 按艺人筛选并自动生成播放列表

筛选艺人并创建播放列表是批量整理最常见的需求。核心是CreatePlaylist建列表、AddTrack往列表里加曲目。这里有一条重要经验：不要在遍历集合的同时往播放列表里加歌，因为集合内部的迭代可能会受到COM调用的影响，稳妥做法是先把匹配的曲目收集到std::vector，遍历完再统一添加。

#include <vector> void BuildPlaylistByArtist(IITiTunesPtr& spITunes, const wchar_t* artist) { IITLibraryPlaylistPtr spLib = spITunes->LibraryPlaylist; IITTrackCollectionPtr spTracks = spLib->Tracks; long nCount = spTracks->Count; std::vector<IITTrackPtr> matched; for (long i = 1; i <= nCount; ++i) { IITTrackPtr spTrack = spTracks->Item[i]; if (spTrack == nullptr) continue; _bstr_t bArtist = spTrack->Artist; if (bArtist.length() > 0 && _wcsicmp((wchar_t*)bArtist, artist) == 0) { matched.push_back(spTrack); // 先攒着，不打断遍历 } } if (matched.empty()) { wprintf(L"没有找到艺人 %s 的曲目\n", artist); return; } wchar_t listName[256]; swprintf_s(listName, L"%s 精选", artist); // 同名播放列表已存在时CreatePlaylist会失败，调用前要检查 IITPlaylistPtr spPlaylist = spITunes->CreatePlaylist(_bstr_t(listName)); if (spPlaylist == nullptr) { wprintf(L"创建播放列表失败，可能名字重复: %s\n", listName); return; } for (size_t j = 0; j < matched.size(); ++j) { // 第二个参数控制“添加后立即开始播放”，批量操作统一传FALSE spPlaylist->AddTrack(matched[j], VARIANT_FALSE); } wprintf(L"已创建播放列表 %s，共添加 %zu 首曲目\n", listName, matched.size()); }

_wcsicmp做不区分大小写的宽字符比较，兼容英文大小写差异；中文匹配时直接按编码比较即可。CreatePlaylist如果创建同名列表会失败，生产环境里的做法是先遍历spITunes->Playlists检查重名，或者在失败后自动追加时间戳。AddTrack的第二个参数startPlaying在批量追加时必须传VARIANT_FALSE，否则每加一首歌播放器就跳转一次，用户体验极其糟糕。

3.3 播放控制与状态查询

播放控制是iTunes COM里最直观的一组接口：Play、Pause、NextTrack、PreviousTrack，加上PlayerState状态查询。这里提供一个简单的命令分发函数，方便后面接命令行参数。

void ControlPlayer(IITiTunesPtr& spITunes, const wchar_t* cmd) { if (_wcsicmp(cmd, L"play") == 0) { spITunes->Play(); // 从当前进度继续播放 } else if (_wcsicmp(cmd, L"pause") == 0) { spITunes->Pause(); } else if (_wcsicmp(cmd, L"next") == 0) { spITunes->NextTrack(); // 切到下一首 } else if (_wcsicmp(cmd, L"prev") == 0) { spITunes->PreviousTrack(); } else if (_wcsicmp(cmd, L"status") == 0) { iTunesPlayerState state = spITunes->PlayerState; IITTrackPtr spCur = spITunes->CurrentTrack; if (spCur != nullptr) { wprintf(L"当前曲目: %s，播放状态: %d\n", (wchar_t*)_bstr_t(spCur->Name), (int)state); } } }

iTunesPlayerState枚举的三个主要取值是：停止、播放中、暂停，具体数值以#import生成的枚举定义为准，代码里不要硬编码数字，直接通配枚举名。CurrentTrack在没有播放任何曲目时返回空指针，所以要先判空再访问属性。做轮询状态时建议间隔设在1秒以上，因为每次PlayerState都是跨进程调用，毫秒级轮询会给iTunes进程造成无谓压力。

3.4 导出播放列表为CSV：数据落盘的最小实现

导出歌单到CSV，主要价值是后续可以做离线分析或备份。写CSV有个隐藏坑：直接用fprintf按文本模式写，Windows下换行会被展开成\r\n，但Excel解析时可能把BOM和编码搞混。稳妥做法是用二进制模式写入，并主动加上UTF-8 BOM。

static std::string ToUtf8(const _bstr_t& bstr) { int len = WideCharToMultiByte(CP_UTF8, 0, (wchar_t*)bstr, -1, NULL, 0, NULL, NULL); std::string out(len, 0); WideCharToMultiByte(CP_UTF8, 0, (wchar_t*)bstr, -1, &out[0], len, NULL, NULL); return out; } void ExportPlaylistToCsv(IITPlaylistPtr& spPlaylist, const wchar_t* csvPath) { FILE* fp = nullptr; _wfopen_s(&fp, csvPath, L"wb"); // 二进制写，避免换行被转换 if (!fp) return; const unsigned char bom[] = {0xEF, 0xBB, 0xBF}; // UTF-8 BOM fwrite(bom, 1, sizeof(bom), fp); IITTrackCollectionPtr spTracks = spPlaylist->Tracks; long nCount = spTracks->Count; for (long i = 1; i <= nCount; ++i) { IITTrackPtr spTrack = spTracks->Item[i]; if (spTrack == nullptr) continue; std::string line = ToUtf8(spTrack->Name) + "," + ToUtf8(spTrack->Artist); fwrite(line.c_str(), 1, line.size(), fp); fwrite("\r\n", 1, 2, fp); // 统一用CRLF，兼容Excel } fclose(fp); }

WideCharToMultiByte做UTF-8转换，注意最后一个参数传NULL表示使用默认替换字符。CSV字段如果包含逗号或引号，理论上是需要用双引号包起来的，这里为保持示例可读性省略了转义，生产环境务必补上。BOM那三个字节是给Excel识别UTF-8编码用的，缺了之后中文歌名大概率变成乱码，属于血泪经验。

4. 从示例到工具：封装、命令行与路径转换的落地细节

4.1 封装成类：把COM生命周期收进一个干净对象里

示例代码分散在函数里，一旦功能多了就会失控。我一般会封装一个ITunesClient类，构造时初始化COM并连接iTunes，析构时按顺序释放，外部只看到业务方法。这样调用方不用关心COM细节，也更方便写单元测试。

class ITunesClient { public: ITunesClient() : m_connected(false) { // 构造阶段完成COM初始化与连接 HRESULT hr = CoInitializeEx(NULL, COINIT_MULTITHREADED); if (SUCCEEDED(hr) || hr == RPC_E_CHANGED_MODE) { m_connected = SUCCEEDED(m_spITunes.CreateInstance("iTunes.Application")); } } ~ITunesClient() { // 先释放智能指针，再关闭COM m_spITunes = nullptr; CoUninitialize(); } bool IsConnected() const { return m_connected; } IITiTunesPtr& GetITunes() { return m_spITunes; } private: IITiTunesPtr m_spITunes; bool m_connected; };

构造函数里的RPC_E_CHANGED_MODE容忍意味着：如果调用线程之前已经被初始化为其他套间，这个类仍然可以工作。析构顺序是反过来的：先置空智能指针触发代理释放，再调CoUninitialize。这个顺序一旦颠倒，某些iTunes版本会出现退出时崩溃的玄学问题。IsConnected只表示创建实例成功，运行中iTunes被退出后，方法调用会失败，所以业务层仍需要捕获异常并触发重连。

4.2 iTunes路径与Windows路径转换：访问本地文件前的必要步骤

IITTrack的Location属性返回的是文件路径，但格式是URL风格，典型值长这样：file://localhost/Z:/Music/01.mp3。直接拿这个字符串去fopen一定会失败，必须转换。转换包含两步：去掉file://localhost/前缀，把正斜杠换成反斜杠。

#include <atlconv.h> std::wstring ITunesUrlToWinPath(const std::wstring& url) { std::wstring path = url; const wchar_t* prefix = L"file://localhost/"; if (path.rfind(prefix, 0) == 0) { path = path.substr(wcslen(prefix)); } for (auto& ch : path) { if (ch == L'/') ch = L'\\'; // POSIX斜杠转Windows反斜杠 } // 注意：URL里的%20等百分号编码还需要再做一次解码 return path; }

这个函数能应对绝大多数情况，但有一个边界坑：如果路径里有空格，URL里会编码成%20，上面的代码不会自动解码。需要再调UrlUnescapeW把百分号编码还原。顺序是先去前缀，再解码，最后换斜杠。另外iTunes返回的盘符可能是大写也可能不是，Windows文件系统不区分大小写，这块不敏感。

4.3 命令行参数化：一条命令完成歌单导出

把功能做成命令行工具，比每次改代码重新编译实用得多。用wmain接收宽字符参数，按子命令分发。这里给出核心分发逻辑：

int wmain(int argc, wchar_t* argv[]) { if (argc < 2) { wprintf(L"用法: itunes_tool.exe -export <歌单名> -out <CSV路径>\n"); wprintf(L" itunes_tool.exe -play <歌单名>\n"); return 1; } ITunesClient client; if (!client.IsConnected()) { wprintf(L"无法连接iTunes\n"); return 1; } std::wstring cmd = argv[1]; if (cmd == L"-export") { // 参数解析：-export 歌单名 -out 输出路径 std::wstring playlistName = argv[2]; std::wstring outPath = argv[4]; // 按名字查找播放列表后导出... } else if (cmd == L"-play") { // 按名字查找播放列表并调用Play } return 0; }

命令行解析的完整版应该处理参数缺省、路径带空格加引号等情况。我的习惯是只支持固定顺序的子命令，不做复杂选项解析，减少踩坑面。这个工具的典型用法是：itunes_tool.exe -export "深夜歌单" -out D:\backup\深夜歌单.csv，配合计划任务就能实现每周自动备份歌单。

4.4 排错基本功：把HRESULT和COM调用日志留全

COM开发最常见的翻车点就是HRESULT返回失败但看不出在哪一步。一劳永逸的办法是封装一个带日志的调用宏，每次COM方法调用失败都把表达式、错误码和可读信息打出来。

#define CHECK_HR(expr) do { \ HRESULT __hr = (expr); \ if (FAILED(__hr)) { \ _com_error err(__hr); \ wprintf(L"调用失败: %s | 0x%08X | %s\n", \ L#expr, __hr, err.ErrorMessage()); \ return __hr; \ } \ } while (0)

这个宏把出错表达式通过L#expr变成字符串，日志里能直接看到哪一行调用失败。_com_error::ErrorMessage()对绝大多数COM错误都能给出可读描述，个别自定义错误码只显示HRESULT数值，这时去查winerror.h就够了。日志文件要比控制台输出更可靠，另加一个OutputDebugStringW，方便在调试器里直接看。加了这套日志之后，大部分问题不再需要逐行断点。

5. iTunes C++开发避坑：从COM套间到32/64位边界的5个典型故障

5.1 现象：64位程序连不上iTunes，返回0x80040154“类未注册”

背景是在64位Windows上编译了一个64位控制台程序，iTunes明明装得好好的，但CreateInstance("iTunes.Application")返回REGDB_E_CLASSNOTREG。原因：iTunes本身是32位程序，它的COM类注册信息写在注册表的32位视图分支里。64位进程查找注册表时，系统默认按64位视图索引，自然找不到这个类。这不是iTunes的坑，是Windows位数隔离的通用规则。

解决很简单：把C++工程的平台从x64改成x86重新编译。VS里路径是“配置管理器→活动解决方案平台→新建→x86”。改完再跑，连接就正常了。如果有人建议你动注册表把32位条目映射到64位视图，千万别试，那会把系统COM状态搞乱。真正需要64位客户端时，正解是做一个32位的代理进程，64位程序通过其他IPC方式和代理通信。

5.2 现象：批量读取几千首曲目时程序卡死，iTunes窗口也像假死

循环遍历媒体库打印属性，前几百首正常，到后面界面整个僵住，有时要十几秒才恢复。原因：每一个属性读取都是一次跨进程COM调用，这些调用会排队进入iTunes进程执行，读取期间iTunes的UI线程也在处理这些请求，客户端主线程又在同步等待结果，两边互相等待，就表现出“都卡住”的样子。

解决思路有三个层次。第一，把批量读取放到独立工作线程，线程里用COINIT_MULTITHREADED，避免占用UI线程；第二，循环里每处理50到100首调用一次Sleep(1)，让iTunes进程的消息循环有机会喘口气；第三，优化访问模式，只读需要的属性，不要在一次循环里把Name、Artist、Album、PlayCount全读一遍然后再读Location，能合并的查询尽量连续做完。实测下来，加了延时后整体耗时不一定会增加多少，但卡死概率大幅下降。

5.3 现象：用户手动关掉iTunes后，程序再调用方法就抛异常

场景是程序已经连上iTunes，播放了几首歌，用户突然手动退出iTunes客户端，程序下一次调用Play或Tracks->Count时抛出_com_error，错误信息类似“对象已断开”或“服务器进程退出”。原因：COM代理的生命周期依赖服务进程，iTunes进程一退出，代理通道立刻失效，缓存的所有接口指针全部作废。

解决：封装一个重连函数，捕获到断连错误后，置空旧指针，重新创建实例。重连后媒体库对象需要重新获取，不要试图复用旧的播放列表指针。这里的关键是重连要及时，并且不要无限重试，连接成功的判断要落到实际的COM调用上，不是CreateInstance成功就算数。

HRESULT ReconnectITunes(IITiTunesPtr& spITunes) { spITunes = nullptr; // 释放旧的失效代理 HRESULT hr = spITunes.CreateInstance("iTunes.Application"); if (SUCCEEDED(hr)) { IITLibraryPlaylistPtr spLib = spITunes->LibraryPlaylist; if (spLib == nullptr) { hr = E_FAIL; // 创建成功但拿不到库，仍算失败 } } return hr; }

5.4 现象：导出的CSV中文全变乱码，文件名也对不上

典型表现：用Excel打开导出的歌单，中文歌名变成一堆“？”或者乱码；用fopen打开Location路径失败，提示找不到文件。这三个症状经常一起出现，根源其实是三件事叠在一起：项目用了多字节字符集导致字符串转换丢字；CSV文件没写UTF-8 BOM，Excel按本地ANSI解析；路径URL里的百分号编码没解码。

解决按顺序来：工程字符集统一改Unicode；写CSV时先写BOM再写UTF-8内容；路径转换函数里补上UrlUnescapeW解码。还有一个容易忽略的小地方：写代码时字符串字面量全用L"..."，不要图省事用"..."让编译器隐式转换，隐式转换在宽窄字符混用时很容易出乱码。这个坑排查起来很费时间，最好在设计阶段就规范好。

5.5 现象：实现了事件接口却收不到播放状态变化

想在曲目切换时自动记录日志，老老实实按COM事件源的方式实现了事件接收器、调用了建议连接，结果回调函数一次都没触发。原因有两层：iTunes的COM事件源要求接收器所在线程运行在单元模型并有消息循环，事件实际是投递到线程消息队列里的，没有消息循环就收不到；另一层是接收器对象在建议连接后被释放了，事件源尝试回调时发现接收器已经失效。

解决：事件接收器持有者要放在一个带消息循环的线程里，最省事的是创建隐藏窗口，在窗口过程里跑事件分发；接收器对象的生命周期必须比建议连接长，程序退出前先断开建议连接，再释放接收器。别把事件回调当成普通函数指针机制看待，COM事件本质上是一套投递机制，需要给系统留出“投递”的通道。这部分的调试难度比前面几条都高，建议一开始就把事件接收器设计成独立组件，别和业务逻辑混在一起。

6. 进阶技巧：用迷你媒体库做回归测试，再加一个无害的dry-run

6.1 为什么先建一个“测试专用迷你媒体库”

直接在真实媒体库上调试批量整理代码，风险太大：创建播放列表会污染真实歌单，误删一曲就是事故。我的做法是准备一个专用的迷你媒体库，放十来个短音频文件，文件命名用固定规则，比如“测试艺人01.mp3”“测试艺人02.mp3”。所有自动化操作都限定建一个叫“自动化测试-临时”的播放列表，跑完就删。这样整个复原过程可重复，删错了也不心疼。

6.2 自检脚本：创建临时列表、加入曲目、断言数量、清理

把核心操作串成一个自检函数，每次改代码后先跑它，确认COM链路和基础接口没被改坏。下面是自检的核心逻辑：

bool RunSelfTest(IITiTunesPtr& spITunes) { // 创建临时播放列表 IITPlaylistPtr spList = spITunes->CreatePlaylist(L"自动化测试-临时"); if (spList == nullptr) return false; // 从媒体库里取前3首曲目加入临时列表 IITLibraryPlaylistPtr spLib = spITunes->LibraryPlaylist; for (long i = 1; i <= 3; ++i) { IITTrackPtr spTrack = spLib->Tracks->Item[i]; if (spTrack != nullptr) { spList->AddTrack(spTrack, VARIANT_FALSE); } } // 断言：临时列表的曲目数等于实际加入的数量 long actual = spList->Tracks->Count; bool ok = (actual == 3); // 清理：删除临时列表 spList->Delete(); return ok; }

Delete()会把播放列表从iTunes里移除，但不会删除媒体库里的原始曲目，所以这个自检是安全的。断言失败时不要继续往下跑，直接返回失败，让上层决定是否中断。养成每次改动后跑自检的习惯，能省掉大量在真实数据上排查的时间。

6.3 dry-run参数：让危险操作先“演一遍”再执行

最后一个值得养成的习惯是给工具加--dry-run开关。导出类操作加它意义不大，但创建播放列表、重命名文件、批量移动文件这类有副作用的操作，先打印“我会做什么”而不实际执行，能避免一堆误操作。实现起来就是在执行前查一下--dry-run参数，有就只打印日志不调用COM方法。

bool dryRun = (ArgExists(argc, argv, L"--dry-run")); if (dryRun) { wprintf(L"[dry-run] 将创建播放列表: %s\n", listName); wprintf(L"[dry-run] 将添加 %zu 首曲目\n", matched.size()); return; // 不执行任何COM修改 }

这段小逻辑的成本极低，但能在关键时刻救回数据。我的习惯是把dryRun放到封装类里，让所有写操作都检查这个开关，而不是只检查命令入口，防止漏网之鱼。做批量整理工具这几年，我最大的教训就是：凡是能改媒体库数据的功能，一律默认先走一遍dry-run；线上翻过车之后，这个习惯再没断过。希望这些经验能帮你少踩几个同样的坑，把iTunes的自动化能力稳稳握在自己手里。

本文还有配套的精品资源，点击获取