从代码搬运到精益求精一次发票打印功能的优化实录最近在实现发票连续打印功能时我复用了一段网上的代码来处理图片转PDF。本以为只是简单的工具类编写没想到一次单元测试却引发了一场关于代码质量、需求理解和用户体验的深度思考。一段“有趣”的代码在编写图片转PDF的单元测试时我发现了这样一段代码protectedvoidscaleImage(com.itextpdf.text.Imageimage){floatimageHeightimage.getScaledHeight();floatimageWidthimage.getScaledWidth();inti0;while(imageHeight500||imageWidth500){image.scalePercent(100-i);i;imageHeightimage.getScaledHeight();imageWidthimage.getScaledWidth();}}这段代码的逻辑很直观如果图片的宽或高大于500像素就循环对其进行缩放直到尺寸符合要求。但有趣或者说“笨拙”的地方在于它采用了一种暴力尝试的方式从100%开始每次减少1%进行尝试直到图片尺寸降到500以下。我的测试图片是795x528这意味着它要一直尝试到62%才符合要求足足循环了38次虽然经过查看itextpdf源码发现scalePercent方法内部主要是纯计算操作执行几千次也无伤大雅但这个逻辑本身确实不够优雅。一个更高效、更简洁的方式是直接计算出缩放比例protectedvoidscaleImage(Imageimage){floatimageHeightimage.getScaledHeight();floatimageWidthimage.getScaledWidth();// 计算适应目标尺寸500所需的缩放百分比floatscalePercentMath.min(500/imageHeight,500/imageWidth)*100;image.scalePercent(scalePercent);}优化之后就完事了吗当我将代码“优化”成直接计算缩放后不禁反问自己做到这一步就算完事了吗显然没有。一个好的功能不是代码能跑通就结束了而是要回答更深层次的问题为什么要把图片缩小到500以内这个“500”是业务需求还是历史遗留为什么生成的PDF是A4纸大小如果图片本身很小周围留白大片不仅浪费“纸张”与其他电子发票合并时也会显得不伦不类。如何与系统中其他PDF文档如OFD转PDF的发票样式统一追根溯源直击本质带着这些问题我重新审视了最终的用户场景——发票合并打印。统一宽度是关键通过与系统中其他格式如OFD转PDF的发票对比我发现它们的宽度基本都是595磅即A4纸的宽度。为了让所有文档在合并后视觉上整齐划一我应该只限制宽度为595而不限制高度。如果限制高度遇到长发票时会被压缩得内容不清。PDF尺寸应与内容契合生成的PDF文档尺寸应该与缩放后的图片大小完全一致而不是固定为A4。这样既能避免浪费“纸张”也能让每个文档都贴合自身内容。基于以上思考我得到了最终的优化版本protectedvoidscaleImage(Imageimage){floatimageWidthimage.getScaledWidth();// 只限制宽度为目标值595高度自适应floatscalePercent595/imageWidth*100;image.scalePercent(scalePercent);}protectedInputStreamimageToPdf(InputStreamis,ListFiletempFiles){FileoutFileFileUtil.createTempFile(.pdf,true);try(FileOutputStreamoutnewFileOutputStream(outFile)){ImageimageImage.getInstance(IoUtil.readBytes(is));// 1. 缩放图片scaleImage(image);// 2. 创建与图片尺寸完全一致的PDF文档并移除所有页边距DocumentdocumentnewDocument(newRectangle(image.getScaledWidth(),image.getScaledHeight()),0,0,0,0);// 关键四周边距设为0PdfWriter.getInstance(document,out);document.open();image.setAlignment(Image.ALIGN_CENTER);document.add(image);document.close();out.flush();returnFiles.newInputStream(outFile.toPath());}catch(Exceptione){log.error(图片转换成pdf失败,e);thrownewBusinessException(图片转换成pdf失败);}finally{IoUtil.close(is);tempFiles.add(outFile);// 用于后续清理}}最终效果合并后的PDF文档中无论是OFD转的发票还是图片转的发票所有页面的宽度都精确对齐高度则随内容自适应。从视觉上看文档流浑然一体完美总结从“能用”到“好用”这段经历让我深刻体会到拥抱代码但要思考直接复制粘贴网上的代码虽然快但可能会埋下性能或逻辑的隐患。读懂它然后优化它。透过现象看本质不要只盯着“如何缩放图片”这个技术点要思考“为什么要缩放”、“缩放后要达到什么业务效果”。用户体验是最终标准代码的优雅、性能的高效最终都要服务于用户看到的那份整洁、统一的PDF文档。那对齐的“绿边”才是这次优化的最大价值。