1. 项目概述与核心价值

最近在做一个Unity项目，客户提了个需求，希望能在游戏里直接打印结算凭证或者角色截图。我第一反应是去找插件，结果发现要么收费不菲，要么兼容性堪忧，要么文档写得云里雾里。折腾一圈下来，我意识到，对于这种需要直接与操作系统底层硬件（比如打印机）打交道的功能，与其依赖第三方黑盒，不如自己动手，用C#和Windows API来实现，反而更可控、更轻量、更符合项目定制化需求。

这个“Unity调用本地打印机打印文件照片”的方案，核心就是绕开Unity生态里那些专门的打印插件，直接利用C#强大的互操作能力，通过P/Invoke调用Windows的GDI+打印接口，或者更简单地，直接调用系统默认的打印关联程序。听起来有点硬核，但实际拆解后，你会发现逻辑非常清晰，代码量也不大。它完美解决了“无需依赖插件”这个痛点，意味着你的项目不会因为一个插件而引入额外的依赖、潜在的许可问题或版本冲突。无论是打印一个文本文件、一张PNG截图，还是PDF文档，只要系统能识别并关联了默认程序，这套方案都能通吃。

特别适合那些项目结构要求干净、对安装包体积敏感，或者需要深度定制打印流程（比如静默打印、指定打印机、设置份数）的开发者。如果你也受够了插件的束缚，想自己掌控打印这个环节，那接下来的内容应该能给你一条清晰的路径。

2. 方案选型与底层原理剖析

2.1 为什么选择系统调用而非Unity插件？

市面上常见的Unity打印插件，其本质也是在底层封装了各个平台（Windows、macOS、Android、iOS）的原生打印API。它们提供了一个统一的C#接口，简化了跨平台开发的复杂度，这是它们的核心价值。然而，这种便利性伴随着一些代价：

1. 黑盒化与调试困难：插件内部如何调用系统API、如何处理异常、内存管理是否得当，对你来说是不可见的。一旦出现“在A电脑能打，在B电脑就打不出”这种玄学问题，排查起来极其痛苦。
2. 功能限制与定制成本：插件提供的是通用功能。如果你的需求稍微特殊一点，比如在打印图片前先加个水印，或者需要获取打印作业的状态回调，插件很可能不支持。此时要么等插件作者更新，要么自己改插件源码（如果有的话），成本反而更高。
3. 依赖与维护风险：项目引入一个插件，就多了一个需要维护的第三方资产。插件是否持续更新以适配新版Unity？是否与项目中的其他插件冲突？这些不确定性都是风险。
4. 平台局限性与冗余：如果你的项目目前只面向Windows PC平台，那么一个为了跨平台而生的插件里包含的iOS、Android代码就成为了冗余，无谓地增加了包体复杂度。

因此，对于明确主要部署在Windows环境的Unity项目（如教育软件、模拟培训、信息亭应用、企业内部工具），直接调用Windows原生打印方式，是一种更直接、更高效、更可控的方案。我们完全可以将平台特定的代码封装在一个独立的C#类中，通过条件编译（#if UNITY_STANDALONE_WIN）来管理，保持项目核心的纯净。

2.2 两种核心实现路径详解

针对“打印文件/照片”，在Windows平台下，主要有两种技术路径，它们的复杂度和控制粒度不同。

路径一：进程调用法（简单粗暴，适用性广）这是最直接的方法。原理是利用System.Diagnostics.Process类，启动一个系统进程，并告诉系统：“用默认的打印程序打开这个文件”。

Process.Start("文件路径");

但更专业的做法是使用verb（动词）参数。在Windows中，文件右键菜单的“打印”就是一个标准的verb。

ProcessStartInfo psi = new ProcessStartInfo { FileName = 文件全路径, Verb = "print", // 关键在这里，指定操作为“打印” CreateNoWindow = true, WindowStyle = ProcessWindowStyle.Hidden }; Process.Start(psi);

工作原理：当执行Verb="print"时，Windows Shell会查找该文件类型关联的默认应用程序，并向该程序发送“打印”命令，而不是“打开”命令。应用程序（如照片查看器、Acrobat Reader、Word）会接收此命令，通常会自动弹出打印对话框，用户确认后即开始打印。

优点：实现极其简单，几乎无需任何打印专业知识。系统负责驱动和格式处理，兼容性好。缺点：控制权低。一定会弹出系统的打印对话框，无法实现“一键静默打印”。打印参数（如打印机选择、份数、纸张方向）依赖于用户在弹出的对话框中设置，或该应用程序记忆的默认设置。

路径二：GDI+ 图形设备接口法（专业控制，功能强大）这是Windows下图形和打印的底层API。Unity的UI和Sprite渲染在某种程度上也借鉴了其思想。通过C#的P/Invoke调用gdi32.dll和winspool.drv中的函数，我们可以直接向打印机发送绘图指令。

核心流程类似于在Unity中创建一个Texture2D并调用Graphics.DrawImage，只不过“画布”变成了打印机的页面。基本步骤是：

1. 启动打印作业：调用StartDoc。
2. 开始一页：调用StartPage。
3. 获取设备上下文（DC）：相当于获取当前页面的“画布”句柄。
4. 在DC上绘制：使用GDI+函数（如Graphics.FromHdc）将你的图片或文本画到这个“画布”上。
5. 结束一页/作业：调用EndPage和EndDoc。

优点：拥有绝对控制权。可以实现静默打印、精确控制每英寸点数（DPI）、混合绘制文本和图形、直接发送原始打印数据（如ESC/POS指令到小票打印机）等高级功能。缺点：实现复杂，涉及大量原生API和句柄管理，容易出错（内存泄漏、资源未释放）。需要对Windows打印体系结构和GDI+有较深理解。

实操心得：对于95%的“Unity打印文件/照片”需求，路径一（进程调用法）已经完全够用且是首选。它的简单性和稳定性远超你的想象。只有当你有“后台无声打印”、“自定义票据格式”、“直接驱动特种打印机”这类硬核需求时，才值得去啃路径二（GDI+）这块硬骨头。本文后续将重点展开最实用的路径一，并对路径二的关键环节进行原理性说明，供有进阶需求的开发者参考。

3. 核心实现：进程调用法完整教程

我们将打造一个健壮的NativeWindowsPrinter工具类，它不仅能处理基本打印，还会考虑异常处理、路径验证、以及一些提升用户体验的细节。

3.1 构建健壮的打印工具类

首先，在Unity项目中创建一个C#脚本，例如NativeWindowsPrinter.cs。我们使用条件编译，确保这段代码只在Windows平台生效。

using System; using System.Diagnostics; using System.IO; using UnityEngine; public static class NativeWindowsPrinter { /// <summary> /// 使用系统默认关联程序打印指定文件 /// </summary> /// <param name="fileFullPath">文件的完整绝对路径</param> /// <param name="silent">是否尝试静默打印（并非所有程序都支持）</param> /// <returns>操作是否成功启动</returns> public static bool PrintFile(string fileFullPath, bool silent = false) { #if !UNITY_STANDALONE_WIN && !UNITY_EDITOR_WIN Debug.LogError("NativeWindowsPrinter 仅支持 Windows 平台。"); return false; #else // 1. 参数校验 if (string.IsNullOrEmpty(fileFullPath)) { Debug.LogError("打印失败：文件路径为空。"); return false; } if (!File.Exists(fileFullPath)) { Debug.LogError($"打印失败：文件不存在于路径：{fileFullPath}"); return false; } // 2. 检查文件扩展名和关联程序（可选但推荐） string extension = Path.GetExtension(fileFullPath).ToLower(); string[] supportedExtensions = { ".pdf", ".jpg", ".jpeg", ".png", ".bmp", ".txt", ".xps" }; if (Array.IndexOf(supportedExtensions, extension) == -1) { Debug.LogWarning($"文件类型 '{extension}' 可能没有关联默认打印程序。尝试继续..."); } try { // 3. 创建并配置进程启动信息 ProcessStartInfo startInfo = new ProcessStartInfo(fileFullPath) { Verb = "print", // 核心：使用“打印”动词 CreateNoWindow = silent, // 尝试隐藏应用程序窗口 WindowStyle = silent ? ProcessWindowStyle.Hidden : ProcessWindowStyle.Normal, UseShellExecute = true // 必须为True才能使用Verb和Shell关联 }; // 4. 启动进程 using (Process process = Process.Start(startInfo)) { // 这里可以添加超时检测或进程状态监控（如果需要） // 例如：process.WaitForExit(10000); // 等待10秒 Debug.Log($"打印指令已发送至系统。文件：{Path.GetFileName(fileFullPath)}"); return true; } } catch (System.ComponentModel.Win32Exception win32Ex) { // 常见错误：没有关联程序，或关联程序无法处理“print”动词 Debug.LogError($"系统拒绝打印请求（Win32错误）。可能该文件类型未关联支持打印的程序。错误详情：{win32Ex.Message}"); return false; } catch (Exception ex) { // 其他未知异常 Debug.LogError($"打印过程中发生未知异常：{ex.Message}"); return false; } #endif } }

3.2 关键参数解析与避坑指南

1. Verb = “print”：这是灵魂所在。它告诉Windows Shell执行默认的打印操作。对于图片，通常会调用“Windows照片查看器”或“画图”的打印功能；对于PDF，则调用Adobe Reader或Edge的打印功能。

2. UseShellExecute = true：这个属性必须设置为true。它表示使用操作系统Shell来启动进程，只有这样Verb参数才会生效。如果设置为false，则是直接执行文件，相当于双击打开。

3. CreateNoWindow和WindowStyle：这两个参数配合，用于尝试隐藏关联程序弹出的窗口。注意，这只是“请求”，最终是否隐藏取决于被调用的应用程序本身是否尊重这些参数。像“记事本”打印可能会弹窗，而一些PDF阅读器可能支持静默模式。所以silent参数命名为“尝试静默”。

4. 文件路径：必须使用绝对路径。Unity中的Application.dataPath、Application.persistentDataPath是常用的获取持久化路径的方法。如果你要打印一个刚截图保存的图片，需要先确保文件已经成功写入磁盘。

5. 异常处理：Win32Exception是最常见的异常，通常意味着文件类型没有关联任何程序，或者关联的程序不支持print这个动词。良好的异常处理能给开发者清晰的调试信息。

注意事项：Process.Start方法成功只代表“启动打印关联程序”这个动作成功了，并不代表打印机已经开始物理打印。打印任务可能进入了系统的打印队列，等待用户在弹出的对话框中点击“确定”。这是此方法无法完全控制的一环。

3.3 在Unity中的典型调用示例

假设我们有一个游戏，在通关后需要打印一张成绩单（保存为PDF）和一张角色纪念截图。

步骤1：准备文件确保你的文件已经生成并保存在本地。例如：

// 假设截图已保存 string screenshotPath = Path.Combine(Application.persistentDataPath, “Screenshot_20231027.png”); // 假设PDF成绩单已生成 string reportPath = Path.Combine(Application.persistentDataPath, “Final_Report.pdf”);

步骤2：创建UI并绑定打印事件在Unity中创建一个按钮，为其Button组件添加监听事件。

using UnityEngine; using UnityEngine.UI; public class PrintDemoUI : MonoBehaviour { public Button printScreenshotBtn; public Button printReportBtn; public Text statusText; private string _screenshotPath; private string _reportPath; void Start() { // 假设路径已赋值 _screenshotPath = ...; _reportPath = ...; printScreenshotBtn.onClick.AddListener(() => PrintImage(_screenshotPath)); printReportBtn.onClick.AddListener(() => PrintFile(_reportPath)); } void PrintImage(string path) { statusText.text = “正在发送图片打印指令...”; bool success = NativeWindowsPrinter.PrintFile(path); statusText.text = success ? “指令发送成功！请查看打印对话框。” : “打印指令发送失败，请检查文件和控制台日志。”; } void PrintFile(string path) { // 可以尝试静默打印PDF（如果阅读器支持） bool success = NativeWindowsPrinter.PrintFile(path, silent: true); // ... 更新状态 } }

4. 进阶探讨：GDI+直接打印原理与关键代码

当进程调用法无法满足需求时（例如开发自助终端机，需要完全无声、无人值守打印），就需要用到GDI+。这里不展开全部代码（那将是一篇独立的万字长文），但会剖析关键步骤和核心代码片段，让你理解其脉络。

4.1 GDI+打印流程框架

整个流程就像在Unity中渲染一帧到RenderTexture，然后提交。

1. 获取打印机信息：使用PrintDocument类或调用EnumPrintersAPI枚举打印机，选择默认或指定的打印机。
2. 配置打印页面：设置PrintDocument的DefaultPageSettings，包括纸张大小（PaperSize）、边距（Margins）、横向/纵向（Landscape）。
3. 订阅打印事件：
   • BeginPrint：打印作业开始时触发，用于初始化资源。
   • PrintPage：核心事件。每打印一页触发一次。在这里进行实际的绘制操作。通过PrintPageEventArgs参数的Graphics对象进行绘制。
   • EndPrint：打印作业结束时触发，用于释放资源。
4. 执行打印：调用PrintDocument.Print()方法。如果是异步打印，可以调用PrintDocument.PrintController进行更精细的控制。

4.2 核心代码片段：打印一张图片

以下是一个高度简化的示例，演示如何在PrintPage事件中绘制一张图片。

using System.Drawing; using System.Drawing.Printing; // 需要引用 System.Drawing.Common NuGet包（在Unity外），Unity内需特殊处理 public class DirectImagePrinter { private Image _imageToPrint; public void PrintImageDirectly(string imagePath) { // 注意：System.Drawing在Unity中不能直接使用，此代码为原理示意。 // 在纯.NET环境或通过复杂封装后可用。 _imageToPrint = Image.FromFile(imagePath); PrintDocument pd = new PrintDocument(); pd.PrintPage += new PrintPageEventHandler(this.PrintPageHandler); // 可以设置打印机 // pd.PrinterSettings.PrinterName = “Your_Printer_Name”; // 设置纸张（例如A4） pd.DefaultPageSettings.PaperSize = new PaperSize(“A4”, 827, 1169); // 单位：百分之一英寸 try { pd.Print(); } finally { _imageToPrint?.Dispose(); } } private void PrintPageHandler(object sender, PrintPageEventArgs e) { // e.Graphics 就是打印页面的“画布” Graphics g = e.Graphics; // 计算图片在页面居中显示 RectangleF pageBounds = e.MarginBounds; RectangleF imageRect = CalculateImageBounds(_imageToPrint, pageBounds); // 将图片绘制到打印画布上 g.DrawImage(_imageToPrint, imageRect); // 如果只有一页，设置HasMorePages为false e.HasMorePages = false; } private RectangleF CalculateImageBounds(Image img, RectangleF pageArea) { // 实现一个保持宽高比的缩放计算逻辑 float ratioX = pageArea.Width / img.Width; float ratioY = pageArea.Height / img.Height; float ratio = Math.Min(ratioX, ratioY); // 选择较小的比例，确保图片完整放入区域 float newWidth = img.Width * ratio; float newHeight = img.Height * ratio; // 居中 float x = pageArea.Left + (pageArea.Width - newWidth) / 2; float y = pageArea.Top + (pageArea.Height - newHeight) / 2; return new RectangleF(x, y, newWidth, newHeight); } }

关键点与挑战：

• Unity兼容性：System.Drawing命名空间在标准的Unity .NET环境下不可用。你需要通过以下两种方式之一解决：
  • 使用兼容库：寻找或编写一个在Unity中可用的、模仿GDI+绘图接口的库。
  • 独立服务程序：将打印逻辑写在一个独立的.NET Framework/Core控制台程序或服务中，Unity通过进程间通信（IPC）或网络请求与之交互。这是更常见、更解耦的工业级方案。
• DPI与缩放：屏幕DPI（通常是96）与打印机DPI（通常是300或600）不同。绘制时必须考虑这个比例，否则打印出来的图片会很小。上面的CalculateImageBounds是一个简单的逻辑，实际中可能需要根据e.Graphics.DpiX和e.Graphics.DpiY进行更精确的换算。
• 字体问题：如果需要打印文本，必须确保打印机或系统拥有你使用的字体，否则会回退到默认字体。

实操心得：在Unity中直接实现完整的GDI+打印是一个非常棘手且不推荐的做法。更优雅的架构是**“前后端分离”：Unity作为前端，负责生成需要打印的数据（如图片字节流、文本内容）。一个用C# .NET Core/WinForms/WPF编写的本地打印服务**作为后端，常驻在系统托盘。两者通过本地HTTP（如使用HttpListener）、WebSocket或命名管道进行通信。Unity发送打印请求和数据，服务负责调用GDI+完成高质量、可控制的打印。这样既利用了Unity的渲染能力，又发挥了原生.NET在打印上的稳定性。

5. 实战问题排查与经验实录

即使采用简单的进程调用法，在实际部署中你也会遇到各种意想不到的问题。下面是我踩过的一些坑和解决方案。

5.1 常见问题速查表

5.2 性能与用户体验优化技巧

1. 异步操作与UI反馈：打印，尤其是启动外部程序，可能耗时几百毫秒到几秒。一定要在UI上给出明确的状态反馈（如“正在准备打印...”），并将打印调用放在异步操作中，避免阻塞主线程导致游戏卡顿。可以使用async/await包装Process.Start，或者使用ThreadPool.QueueUserWorkItem。

2. 文件格式选择：对于打印，推荐使用PDF格式。它是为打印而生的格式，能跨平台、跨程序保持格式一致。如果打印图片，JPEG或PNG是通用选择。避免使用BMP等未压缩格式，文件太大会影响传输和加载速度。

3. 生成可打印文件：Unity中生成PDF需要第三方库（如PDFSharp、iTextSharp的移植版本）。生成图片则简单得多，使用ScreenCapture.CaptureScreenshot或Texture2D.ReadPixels即可。记得在保存图片时，根据打印需求设置合适的分辨率。屏幕截图通常是72/96 DPI，而打印需要300 DPI。你可以通过设置一个大的渲染目标（RenderTexture）来生成高分辨率图片。

4. 备用方案（降级策略）：如果你的应用至关重要，可以考虑实现一个备用打印方案。例如，当直接打印失败时，将文件保存到一个指定文件夹，并弹窗提示用户：“打印指令发送失败，文件已保存在 [路径]，您可以手动打开并打印。” 这比完全失败的用户体验要好得多。

5. 清理残留进程：虽然我们用了using语句，但被启动的关联程序（如照片查看器）可能不会自动关闭。对于长时间运行的应用（如信息亭），可以考虑在打印任务发起后一段时间，温和地尝试关闭这些进程，避免内存累积。但这需要谨慎，避免关闭用户正在使用的程序。

6. 跨平台考量与架构建议

虽然本文聚焦Windows，但作为Unity开发者，心中必须有跨平台的蓝图。一个健壮的打印架构应该易于扩展。

核心思想：抽象与平台实现分离定义一个统一的打印接口IPrintService：

public interface IPrintService { bool PrintFile(string filePath, PrintOptions options); Task<bool> PrintFileAsync(string filePath, PrintOptions options); } public class PrintOptions { public string PrinterName { get; set; } public int Copies { get; set; } = 1; public bool IsSilent { get; set; } // ... 其他选项 }

然后为不同平台创建实现类：

• WindowsPrintService：封装本文所述的进程调用法或GDI+。
• MacPrintService：使用macOS的osascript命令调用AppleScript进行打印。

  osascript -e ‘tell application “Preview” to open POSIX file “/path/to/file.pdf”’ -e ‘tell application “System Events” to tell process “Preview” to keystroke “p” using command down’

• AndroidPrintService：使用Android的PrintManagerAPI，通过Android Java插件或Unity的Android SDK与Java层交互。
• iOSPrintService：使用iOS的UIPrintInteractionController，通过Unity的iOS原生插件调用。

最后，在Unity中使用一个工厂类或依赖注入，在运行时根据编译平台条件实例化对应的IPrintService。

这套架构的初始搭建需要一些工作量，但它使得打印功能成为了一个可维护、可测试、可扩展的模块。当未来需要支持一个新的平台，或者替换某个平台的实现时，影响范围被严格限制在了对应的服务类中，项目的主体逻辑完全不受影响。这才是应对Unity多平台开发复杂性的正确姿势。