windows下用shellexecute调用"print"动词静默打印pdf最轻量可靠，需传绝对路径、依赖默认关联程序，不阻塞线程；linux/macos用lp命令，依赖cups配置。

Windows平台下用ShellExecute启动默认打印机

直接调用系统打印命令是最轻量、最可靠的方式，不需要链接GDI或Windows SDK复杂API。关键在于让Windows自己解析文档类型并交给默认打印机处理。

常见错误是试图用CreateProcess硬启print.exe，但该工具只支持纯文本，对PDF、DOCX等会失败或静默忽略。

• 使用ShellExecute（shellapi.h），传入"print"操作和文档绝对路径
• 必须确保路径是完整绝对路径，相对路径会导致ERROR_FILE_NOT_FOUND
• 文档格式需有已注册的默认关联程序（如Acrobat Reader关联网PDF，Word关联网DOCX）
• 不阻塞主线程，后台异步执行；如需等待完成，得改用ShellExecuteEx + WaitForSingleObject

#include <shellapi.h>
// ...
ShellExecute(NULL, "print", "C:\report.pdf", NULL, NULL, SW_HIDE);
</shellapi.h>

Linux/macOS上通过system调用lp命令

类Unix系统没有“默认打印机”抽象概念，而是依赖CUPS配置。真正起作用的是lp命令本身——它自动读取LPDEST环境变量或~/.cups/lpoptions， fallback到系统默认队列。

容易踩的坑是权限问题：lp需要用户属于lp或sys组，否则报lp: Unable to connect to server。

C函数速查手册（CHM版）

C函数速查手册（CHM版）

下载

• 用system("lp /path/to/file.pdf")即可，无需指定打印机名
• PDF/PostScript文件可直打；文本文件建议加-o document-format=text/plain避免乱码
• 避免在无CUPS环境（如Docker最小镜像）中调用，会卡住或返回127
• macOS同理，lp走CUPS，但部分M1/M2 Mac可能需先运行sudo cupsctl --remote-admin启用远程管理

跨平台封装要注意的三件事

真要写一次代码跑多平台，别自己拼命令字符串——路径分隔符、空格转义、编码（尤其Windows中文路径）、后台进程生命周期都不同。

• Windows下路径含空格必须用双引号包裹："C:\My Documents\file.pdf" → ShellExecute(..., "print", ""C:\My Documents\file.pdf"", ...)
• Linux/macOS下空格路径也要引号，且需std::string拼接时转义：用"而非"
• 不要假设lp或ShellExecute一定成功：检查返回值（Windows下reinterpret_cast<int_ptr>(ret) 表示失败；Linux下<code>system()返回值需用WEXITSTATUS提取）

为什么不要用GDI或Qt PrintSupport做“控制打印”

如果目标只是“把现有文档发给默认打印机”，用底层绘图API或框架打印模块是过度设计，还引入新依赖和兼容性风险。

典型表现：Qt的QPrinter + QPrintDialog会弹窗选打印机，破坏自动化；GDI的StartDoc系列要求自己解析PDF/DOCX为GDI指令，实际不可行。

• 除非你要自定义页边距、双面、份数等参数，否则绕开这些API
• 设置份数？Windows可在ShellExecute参数里加/d"n"（仅部分应用支持）；Linux用lp -n 2 file.pdf
• 获取默认打印机名？Windows查注册表HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\DefaultSpoolDirectory不靠谱，应调GetDefaultPrinter；Linux用lpstat -d解析stdout

默认打印机这层抽象，操作系统已经做得足够好——你只需要告诉它“打印这个文件”，而不是接管整个打印流水线。

C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！