打印机SDK二次开发：环境配置、最小打印链路与六层排错

1. 拿到SDK压缩包之后，先别急着写代码

很多人做打印机对接，第一反应是打开IDE建工程、找示例代码粘进去跑。但我接触过的项目里，十次有八次卡住的地方根本不在写代码这一步，而是在拿到SDK压缩包之后的头两小时里——目录看不懂、文档找不到入口、示例工程编译报错、库文件位数对不上。这些琐碎问题一旦处理不好，后面所有工作都是空转。

这次要聊的就是打印机SDK的二次开发落地过程：拿到一个厂商提供的打印开发包，从解压、读文档、配环境，到真正调通一版打印输出，最后把常见的坑一个个填平。适合两类人看：一类是刚接手打印模块、之前只写过上层业务代码的同学；另一类是已经跑通了Demo，但一换机器、一换纸张规格就出各种怪问题的开发者。整个过程的思路是通用的，不绑定某一款具体机型，但为了讲得具体，我会以常见的打印开发包结构为蓝本展开，型号层面的差异我会明确标出来。

先说一个总的原则：SDK对接不是"调用一个函数"的事，而是"建立一个可重复验证的实验环境"的事。打印这条链路上有太多不可见的环节——驱动、端口、纸张、字体、编码、固件版本，任何一环不对，最终症状都是同一句话："打不出来"或者"打出来是乱码"。如果你没有一套能逐层剥离的实验方法，就只能靠猜。而我从实际项目里得到的教训是：靠猜浪费的时间，是做实验的十倍以上。

所以这篇文章不会一上来就给你一大段示例代码。我会先讲怎么把SDK这个"黑盒"拆成看得见的零件，再讲怎么用最小的代码量打出第一张纸，最后讲怎么把这套东西变成稳定可维护的模块。

1.1 压缩包解压后第一件要做的事：画一张目录地图

大部分厂商的打印开发包解压出来是这么个结构（具体名称各家不同，但分层逻辑高度相似）：

解压之后我建议直接动手做三件事，花不了十分钟，但能省掉后面几小时：

第一，把Doc里的文件按"读的顺序"重命名或建个索引。厂商文档经常是十几个PDF，命名毫无规律，什么Manual_v2.pdf、API_List_new.pdf、Readme_CN.txt。你不需要全读，通常只有三份是必须的：接口总览（有哪些能力）、初始化与连接章节（怎么连上设备）、错误码表（出错怎么查）。把这三份找出来，其余的先放着。

第二，确认库文件的位数和编译器匹配情况。打开Lib目录，看是不是分了x86、x64、arm64这类子目录。这里有个非常常见的坑：你的工程是64位，但只引了32位的库，编译期可能只是警告，运行期直接抛"无法加载DLL"或者干脆进程静默退出。尤其在托管语言里调原生库时，这个错误的表现形式特别隐蔽。

第三，把示例工程原封不动编译一次。注意是"原封不动"，不要改任何配置，先确认它能在你的机器上跑起来。这一步的价值在于：它能证明SDK本身在你的环境里是完好的。如果示例都跑不起来，你去改自己的工程就是浪费时间。如果示例能跑，你的工程跑不起来，那问题一定在你的工程配置，排查范围立刻缩小一半。

提示：解压路径里不要带中文和空格。这条老规矩到现在依然有效，很多原生库在加载依赖时对路径处理很不严谨，一个空格就能让它在某些系统上找不到自己的配置文件。

1.2 判断这套SDK属于哪一类，决定了后面所有写法

打印开发包大致分三种类型。搞清楚你手上这套是哪一类，比读十页API文档都重要，因为它们的调用模型完全不同。

第一类是"驱动封装型"。这类SDK自己不做排版渲染，它依赖系统里已经装好的打印机驱动，只负责把数据丢给驱动、查询状态。它的优点是上手快，系统驱动帮你处理了大部分机型适配；缺点是可控性差，纸张、边距、分辨率这些参数受驱动设置影响很大，容易出现"代码里设了A4，打出来是Letter"的诡异现象。

第二类是"直接控制型"。这类SDK绕过系统驱动，直接通过端口（USB、网口、串口）和打印机通信，自己构造打印指令。可控性极强，能精确控制每一行、每个指令，速度快、体积小；代价是你得自己处理字符编码、位图转换、切纸、走纸这些底层细节，出错时也更难排查。

第三类是"混合型"，通常提供两套接口，简单场景走驱动，复杂场景走直连。这类包最容易让人迷路，因为文档里两套接口混在一起讲。

怎么快速判断？看头文件里的接口名。如果接口参数里频繁出现"printer name""document name""job"这类概念，还能设置"是否弹出打印对话框"，基本是驱动封装型；如果接口参数里出现"port""baud rate""command""buffer"，或者有Write、SendData这类方法，基本是直接控制型。

这个判断影响什么？影响你的调试手段。驱动封装型的排查重点在"系统驱动和打印队列"，你要会看打印队列卡在哪、驱动版本对不对；直接控制型的排查重点在"数据是否真的发出去了"，你要会抓端口数据、会看设备返回值。方向错了，排查就是无效劳动。

我在一个项目里就吃过这个亏。当时现象是"偶尔能打，偶尔打不出来"，我按驱动封装的思路查了两天打印队列，一无所获。后来才发现这套SDK是直连型的，问题实际出在端口被另一个进程短暂占用——这是完全不同的排查方向。先定性，再动手，这六个字值不少时间。

2. 环境配置：真正容易翻车的三个位置

环境配置听起来是最没技术含量的环节，但实际项目里，初始化阶段的失败占了我见过的问题的一多半。而且这类问题的特点是：报错信息极其模糊，往往就是"初始化失败""返回错误码-1"，没有任何有效线索。下面三个位置是我反复踩过、也反复看到别人踩的地方。

2.1 位数、运行库与依赖链，缺一个都起不来

原生库的加载是个链条：你的程序 → SDK的主库 → SDK依赖的第三方库 → 系统运行库。任何一环缺失，表现出来的都是"加载失败"，但原因完全不同。我一般按这个顺序查：

1. 位数核对。任务管理器看你的进程是32位还是64位，和库目录对照。这一步五秒钟，但能解决相当比例的问题。
2. 依赖库完整性。SDK的Bin目录里通常不止一个文件，可能有图像处理库、通信库、配置库。很多人的错误做法是只把主库拷到输出目录，结果运行时提示找不到某个从未听说过的模块。正确做法是把Bin下所有运行时文件一起拷过去。
3. 系统运行库版本。部分SDK是用较新的工具链编译的，依赖特定版本的运行库。如果你的目标机器是老系统，或者装了多个版本导致冲突，就会出现"开发机好好的，客户机器起不来"。这种情况我通常会在目标环境里跑一次依赖检查工具，把缺失的模块一次性列出来。

这里有个特别隐蔽的情况值得单独说：开发机能跑，部署到另一台机器就失败，且没有任何报错。这往往不是依赖缺失，而是异常被吞掉了。原生库在某些情况下加载失败不会抛异常，而是返回空句柄，如果上层代码没做判空就直接调用，进程会直接退出，日志里什么都没有。所以我在封装初始化函数时，一定会对每个返回句柄做显式判空，并打印出具体是哪一步失败。这条习惯救过我很多次。

2.2 端口与设备识别：别假设你的机器和开发机一样

设备连接方式不同，初始化前的准备工作也不同，我把常见情况整理成一张对照表，实际项目里直接照着核对：

USB这块最常见的坑是设备被独占。打印机在同一时刻通常只能被一个进程打开。如果你的系统里装了一个状态监视工具，或者上一次调试的进程没有正常退出，端口就一直被占着，新进程怎么都连不上。我遇到这种情况的标准动作是：关掉所有相关工具，检查任务管理器里有没有残留进程，必要时把设备断电重连一次。不要在这上面纠结代码，先确认端口是干净的。

网络连接的坑更微妙一些。除了IP和端口，多网卡环境经常出问题：机器上同时有有线和无线网卡，程序默认走了错误的那块网卡，导致明明能ping通却连不上。这种问题在有虚拟网卡的开发机上尤其常见。排查方法是临时禁用无关网卡试一次，如果立刻通了，就说明是路由出口的问题，需要在代码或系统层面指定出口。

串口的话，参数必须和设备端完全一致。我一个同事调了一下午，最后发现是校验位设错了——设备要求无校验，代码里写了偶校验。这种错误的表现就是"有数据但全是乱码"，很容易被误判成编码问题。

2.3 初始化顺序：调错顺序，后面全是玄学

SDK的初始化通常有个隐含顺序，文档里可能只在某一页角落提了一句，但顺序错了就会出现各种难以解释的现象。典型顺序是：加载库 → 创建实例/句柄 → 设置连接参数 → 打开连接 → 查询设备状态 → 开始任务。

我想强调的是倒数第二步——查询设备状态。这一步很多人省掉，觉得连上就能打。但实际项目里，省掉这一步会导致两类问题：一是设备处于异常状态（缺纸、开盖、未就绪）时，你的打印任务会静静地失败，且没有明确提示；二是某些设备需要在查询状态后才真正完成就绪，跳过它会导致第一批数据被丢弃。

所以我的习惯是在初始化完成后立刻做一次状态查询，把结果打日志。这行日志在后续排错时价值极高——它能告诉你"问题发生在连接阶段"还是"问题发生在打印阶段"，这两个阶段的排查路径完全不同。

注意：如果你的程序是多线程的，初始化函数通常不是线程安全的。我见过在多个线程里同时调初始化，导致句柄互相覆盖、行为诡异。规范做法是初始化放在主线程、单次执行，之后把句柄传给工作线程使用。

3. 打出第一张纸：最小可用路径的完整拆解

现在环境通了，接下来要做的是用最少的代码打出第一张纸。我特别强调"最少"——这个阶段的目标不是做一个能用的打印功能，而是打通链路、验证每一环。代码越少，出问题时可疑的地方就越少。

3.1 先决定"打什么"，再决定"怎么打"

这一步很多人忽略，但它直接决定你后面写多少代码。打印内容大致分四类，难度和技术路线差别很大：

纯文本是最合适的起点。它只依赖最基本的发送接口，能验证连接、编码、走纸这三件事。我建议第一版就打印三行字加一个换行，跑通了再往上加复杂度。

如果你的项目最终要打的是结构化单据，也不要一上来就画表格。先用纯文本验证链路，再把文本替换成"按坐标画一行字"，最后才是完整表格。每加一层都验证一次，出问题时你就知道是哪一层引入的。这个"分层递进"的方法是我做所有硬件对接类项目的通用套路，比一次写完再调试效率高得多。

3.2 编码：乱码问题的根源几乎全在这里

打印中文最容易出的问题就是乱码。原因不外乎三种：你发的编码和打印机理解的编码不一致、打印机固件不支持该字符集、传输过程中字节被截断或转换。

先说要害：不要把"字符串"这个概念带进底层发送环节。在直连型SDK里，你发送的应该是一个明确的字节序列，而不是一个语言层面的字符串。很多语言在字符串转字节时会用默认编码，这个默认值在不同平台、不同配置下可能不一样，于是代码看起来没变，换台机器就乱码了。

我的处理原则是：

• 明确指定编码，不要依赖默认值。涉及中文时，常用的是GBK系列或UTF-8，具体看设备支持哪种，这个必须查文档或实测确认，不能猜。
• 传输前打印出字节的十六进制，和设备能识别的编码做比对。这一步看着笨，但它是唯一能确定性定位乱码原因的方法。
• 若设备只支持单字节字符集，中文就必须走位图方案，不要再纠结编码。

还有一种情况值得提醒：部分设备的字符集是可切换的，通过一条指令设置。如果你发了切换指令但没生效，可能是指令格式不对，也可能是切换后需要复位。这类问题只能靠抓取"设备认可的样例数据"来反推——找一个厂商提供的、确定能正常打印的样例，把它实际发出的字节抓下来，和你的做逐字节对比。这是解决编码问题最快的路径，比读文档猜要快得多。

3.3 走纸、切纸与任务结束：别让最后一步毁掉整张单

打出来了，但内容位置偏了、或者最后一段被切掉、或者连续打两张时第二张错位——这些问题的根源往往在"任务边界"的处理上。

几个必须明确的点：

• 换行符。不同设备对\n、\r\n的响应不同，有的只认\r\n，只发\n会导致所有内容挤在一行。这个在纯文本阶段就要验证清楚。
• 走纸量。打完内容后通常需要走纸到切纸位置，走纸行数不够会导致内容被切纸刀切掉一部分。走纸量一般按行数或点行数设置，具体单位必须查文档，搞错了就是多走或少走一大截。
• 切纸指令。不是所有机型都支持切纸，不带切纸器的机型发切纸指令可能被忽略，也可能导致异常。要先确认机型能力。
• 任务结束标志。部分SDK要求显式调用"结束任务"或"关闭文档"，不调用的话数据可能停留在缓冲区不发出。这个是最容易漏的一步，症状是"代码全对但不出纸"，很多人会往连接和编码上找，其实是没结束任务。

我在第一次做这类对接时，就是漏了结束任务这一步，折腾了快两个小时。后来养成习惯：每写完一段打印逻辑，先检查有没有配对的开头和结尾调用，就像检查括号是否配对一样。

3.4 一个可直接参考的最小流程

下面是这个阶段我通常写的骨架，语言用伪代码风格，重点是流程而非语法：

1. 加载库 2. 创建句柄（判空） 3. 设置连接参数（端口/IP、超时） 4. 打开连接（判返回值） 5. 查询状态（打印到日志） 6. 开始任务 7. 发送初始化指令（复位、设置编码） 8. 发送内容字节（明确编码） 9. 发送换行 / 走纸指令 10. 结束任务 11. 关闭连接、释放句柄 12. 每一步的返回值都打印日志

这十二步里，第 6 到第 10 步是最容易出错的区间。我建议第一次跑的时候，在每一步之间加一句日志输出，确认执行到哪一步、返回值是什么。等跑通了再删掉冗余日志。有人觉得这样代码脏，但调试期的日志就是你唯一的眼睛。

还有一点：释放资源要放在异常安全的路径上。如果中间某步失败就return了，句柄和连接没释放，下次运行就可能遇到"端口被占用"。哪怕是临时脚本，也建议用try/finally（或对应语言的等价机制）确保释放。

4. 排错：把"打不出来"拆成可验证的六层

这是整篇文章里我认为最有价值的部分。因为对接打印设备，最终拉开差距的不是会不会调API，而是面对一个模糊症状时，能不能快速缩小范围。

我的做法是把整条链路分成六层，从下往上逐层验证。每一层都有明确的"通过标准"，通过了就往上走，不通过就在这一层深挖：

这个表的用法是：从第1层开始，不要跳层。我见过太多人直接从第3层开始查代码，结果折腾半天发现是设备没纸。听起来荒谬，但真实项目里"缺纸导致打印失败"这种情况出现的频率远超想象，尤其是远程协助客户排查的时候。

4.1 第1到3层：先排除"根本不是代码的问题"

设备自检是所有排查的起点。绝大多数打印设备都支持按住某个键开机打出自检页，这一页能打出来，说明物理连接、耗材、机芯都正常。自检页打不出来，就别看代码了，先解决硬件和耗材问题。

第2层看系统。系统里能不能看到设备、状态是不是"就绪"、有没有报错标记。这一步在驱动封装型方案里尤其关键，因为你的代码实际是在和驱动打交道。系统层面有黄色感叹号，代码怎么写都没用。

第3层才轮到代码。打开连接返回失败，原因可能是端口被占、IP不通、参数错误。这时候前面提到的"每一步打日志"就派上用场了。要区分"连接打开失败"和"连接打开成功但后续发送失败"，这两种情况的排查方向完全不同。

有个小技巧分享一下：如果你怀疑是端口占用，可以在打开连接失败后，尝试打印出系统当前的端口占用情况，或者简单地重启设备再试一次。如果重启后能连上，基本就确认是占用问题。用"重启设备"这个动作来做判定，比分析代码快得多。

4.2 第4层：证明数据真的发出去了

这一层最容易被跳过，因为很多人默认"调用了发送函数就等于发出去了"。实际上发送函数返回成功，只代表数据进了缓冲区，不代表到了设备。

怎么证明？最简单的办法是发一条能让设备产生可见反应的指令，比如走纸、或者打印一行极短的内容。如果设备走纸了，说明通信链路是通的，问题在内容解析；如果一点反应都没有，问题在通信层。

在网络连接的情况下，我还会用抓包工具看数据是否真的从本机发出、设备是否有回包。有发无回通常意味着设备没收到或者拒绝处理；根本没发说明卡在了SDK内部，可能是缓冲区没刷新、也可能是任务没结束。

缓冲区这个事值得单独说：部分SDK采用缓冲发送，数据攒够一定量或者显式刷新才发出。如果你的内容很短，可能一直躺在缓冲区里。症状是"程序执行完了，设备毫无动静"，然后你随便再打个长一点的东西，前面那点内容突然一起出来了。遇到这种"延迟出现"的现象，优先怀疑缓冲区没刷新。

4.3 第5层：内容正确性排查的对照法

到了这一层，通信是通的，但打出来不对。表现有：乱码、位置偏移、内容截断、图形变形。我用的方法是对照法——准备三份数据，逐一比对：

1. 厂商样例数据：文档里或示例工程里确定能正常打印的那份。
2. 你的数据：你实际发送的字节。
3. 设备输出：实际打出来的效果。

先把样例数据发出去，确认能正常打印（这一步验证设备和你的发送通道没问题）。然后把你的数据和样例做逐字节对比，找出差异。差异通常集中在几个地方：编码声明、初始化指令、换行符、单位换算。

位置偏移的排查思路不同。位置问题基本都和坐标单位有关：设备用的是点（dot）还是毫米，分辨率是203dpi还是300dpi。同样是"向右100"，在203dpi下和300dpi下差了近一半。换算公式很简单：

实际点数 = 物理尺寸(mm) ÷ 25.4 × 分辨率(dpi)

比如要在300dpi的设备上偏移20毫米：20 ÷ 25.4 × 300 ≈ 236点。这个换算必须自己算清楚并写成常量或函数，不要在各个地方手写魔法数字，否则改一次分辨率就要改几十处，还容易漏。

图形变形通常是位深或宽度对齐的问题。有些设备要求位图每行字节数按4字节对齐，不满足就会错位。这类问题查文档的"位图数据格式"章节，或者直接用设备能正常打印的位图做对比。

4.4 第6层：连续打印与异常恢复才是生产标准

单张能打，不代表能用。生产环境的要求是：连续打一百张不出错、中途断线能恢复、断电重来不残留脏状态。这一层的问题往往在开发阶段完全暴露不出来。

几个高频问题：

• 句柄泄漏。每次打印都创建句柄但不释放，打几十次之后就开始失败。排查方法是长时间循环打印，同时观察进程的资源占用是否持续增长。
• 状态未复位。上一次打印异常中断，设备停在某个中间状态，下一次打印直接错乱。规范做法是每次任务开始前发一次复位/初始化指令，不要假设设备是干净的。
• 断线重连。网络抖动导致的断开，如果不做重连，后续所有任务都会失败。重连逻辑要注意：重连后必须重新查询状态、重新初始化，不能直接续发。
• 并发冲突。多个线程或进程同时打印，数据会交错。要么加锁串行化，要么用任务队列。

我个人的经验是：在开发阶段就写一个循环打印的测试脚本，跑一百次，观察成功率和资源占用。这个脚本写起来十分钟，但能在上线前发现绝大部分稳定性问题。等客户投诉"打几十张就卡住"再去查，成本高得多。

5. 把跑通的代码变成能维护的模块

Demo跑通只是起点。真正交付的时候，代码要能应对机型差异、参数变化、异常情况，还要让别人看得懂。这一节讲我在实际项目里沉淀下来的几个做法。

5.1 把机型差异收敛到一个配置层

不同机型在分辨率、纸张宽度、支持的指令集、是否支持切纸这些方面都不一样。如果这些差异散落在业务代码里，每接一个新机型就要改一堆地方，还容易漏。

我的做法是定义一个"设备能力描述"结构，把所有差异集中起来。伪代码如下：

DeviceProfile { 名称 分辨率dpi 纸张宽度mm 可打印宽度mm 字符编码 是否支持切纸 走纸单位 初始化指令 复位指令 }

业务代码只依赖这个结构，不直接写死任何机型相关的数值。接新机型时只加一个配置项，代码不动。这个设计的价值不在于"优雅"，而在于降低出错概率——人改代码容易漏，改配置相对安全。

坐标换算也放在这一层，提供一个"毫米转点数"的函数，业务代码只传毫米。这样即使分辨率变了，也只影响一个函数。

5.2 日志要能回答"哪一步失败了"

打印类问题的排查高度依赖日志，但日志不是越多越好，而是要在关键节点留下能定位问题的信息。我通常在这几个位置必打日志：

• 初始化每一步的返回值（尤其失败时）。
• 每次任务开始和结束的时间戳、任务标识。
• 发送数据的字节数（不一定要打全部内容，但要知道发了多少）。
• 状态查询的结果。
• 所有异常的完整堆栈。

一条好的日志应该能让你在事后回答："这次失败是在连接阶段还是发送阶段？发送了多少字节？设备当时是什么状态？" 如果日志回答不了这三个问题，说明记得不够。

提示：涉及内容数据的日志要注意脱敏。打印内容里可能有业务敏感信息，调试时可以打，但生产环境的日志策略要提前定好。

5.3 用"模拟异常"来验证恢复逻辑

异常恢复逻辑最难验证，因为异常不好复现。我的办法是主动制造异常：打印过程中拔网线、打印过程中断电、打印中途强制结束进程、故意发一条格式错误的指令。然后观察程序的表现：是否能正确报错、是否能自动恢复、恢复后是否能正常打印。

这个测试做完，你对这套代码的信心会完全不一样。而且很多隐藏的资源泄漏、状态残留问题，只有在这种"破坏性测试"下才会暴露。

6. 几个我踩过、也见过别人踩的坑

前面按流程讲了方法，这里单独把几个反复出现的具体问题拎出来，都是我曾经花了不少时间才搞明白的。

6.1 "示例能跑，我的工程跑不了"的三种典型原因

这个现象太常见了，原因基本集中在三处：

第一，输出目录的依赖文件不全。示例工程通常配置好了生成后自动拷贝依赖库，你自己建的工程没配。解决办法是对照示例工程的生成配置，把拷贝步骤补上。这个问题在托管语言里表现为"找不到指定的模块"，在原生语言里可能是加载时直接失败。

第二，平台目标不一致。示例是x64，你的工程默认可能是Any CPU或者x86。在托管语言里，平台目标会影响加载哪个位数的原生库。

第三，工作目录不同。有些SDK会按相对路径找配置文件或资源文件，示例工程的工作目录和你的不一样，导致找不到。这个问题的症状是"初始化返回失败但没有任何错误说明"。

排查顺序建议按"依赖文件 → 平台目标 → 工作目录"来，从最常见到最不常见。

6.2 中文乱码的三个层次，别搞混了

乱码问题我把它分三层，搞混了就会一直在错误的层里打转：

• 第一层：源数据编码错。你的字节序列本身就不是设备认识的那种编码。验证方法：把字节打印成十六进制，对照编码表看。
• 第二层：传输过程被转换。某些中间层（比如某些字符串处理、某些序列化）会把字节重新编码。验证方法：在发送函数入口处打印字节，和构造时的字节对比。
• 第三层：设备不支持。设备固件只支持单字节字符集，中文字符根本没法表示。验证方法：发英文字符能正常打，发中文就乱，且换几种编码都不行。

第三层最容易被浪费时间去调，因为你会一直尝试各种编码。判断依据很简单：如果设备文档里明确说明字符集范围，先查文档；没有文档，就用英文字符做对照测试。英文正常中文全乱，且多编码尝试均无效，基本可以判定为设备不支持，直接上位图方案。

6.3 位置偏移：分辨率是第一嫌疑

打印内容整体偏移或缩放比例不对，九个里有八个是分辨率设错了。常见情况：

• 设备实际是203dpi，代码里按300dpi换算，打出来的内容会偏小且位置偏左。
• 纸张宽度设置和实际纸张不符，导致右边距计算错误。
• 边距设置了但被设备忽略，因为设备有自己的硬件边距。

排查方法：打一个已知尺寸的图形（比如一个宽100毫米的方块），用尺子量实际打出来的尺寸，反推实际分辨率。这个办法笨，但一次就能确定。

6.4 别忽略固件版本

同一型号的设备，不同固件版本的行为可能不同。我遇到过同一份代码，在A机器上正常、在B机器上位置偏移，最后发现两台机器的固件版本差了好几个。排查到最后如果所有参数都对，就查固件版本。有条件的话，把测试用的设备统一固件版本，能省掉很多"玄学"问题。

7. 关于测试环境的一点个人做法

最后说说测试环境。我现在的习惯是：手边常备一台能随时折腾的设备，并且给它配足耗材。听起来像废话，但缺纸、缺色带导致的排查时间，在我早期项目里占了相当大的比例。设备永远处于就绪状态，你才能专注于代码问题。

另外，我会准备一份"最小验证脚本"，功能就是连上设备、打一行字、查一次状态。每次改完代码或者换环境，先跑这个脚本。它通过，说明基础链路没问题，再跑完整业务。这个习惯让我避免了很多"改了一处结果全崩、不知道崩在哪"的情况。

还有一点：把每一次遇到的怪问题和解决方法记下来。打印这块的知识很多是经验性的，文档里不写，搜索引擎也搜不到，只能靠自己积累。我自己的记录里有几十条，比如某类指令在短数据下需要额外填充、某种走纸指令在某些机型上会多走一行。这些东西记下来就是资产，不记就白踩了。