PHP生成条形码完整Demo：从码制选型到问题排查

简介：这是一份面向PHP初、中级开发者的条形码生成完整示例代码包，适用于电商、库存管理、物流跟踪等需要快速录入与识别条码的场景。资源封装了条形码绘制、颜色设置、字体加载等核心类，并内置多种常用编码类型，例如 Code 128、EAN、UPC 等，开发者可直接部署到 PHP 环境运行，也可按需修改参数实现个性化定制。压缩包共三十二个文件，以二十九个 PHP 源码文件为主，辅以字体文件、条形码定义文件及说明文档，整体仅二百零九 KB，结构清晰、便于对照学习。代码中提供了完整的调用示例，通过示例页面可直观看到生成效果，方便理解条形码从数据到图像的处理流程。目前已有三百七十七人学习下载，适合希望快速掌握 PHP 条形码生成流程并落地到实际项目中的开发者参考借鉴。

1. php生成条形码完成demo：先搞清楚这行搜索背后要解决什么

php生成条形码完成demo，这行字在搜索框里的出现场景，通常是内网系统要打印商品标签、固定资产贴纸或者快递面单。目标很直接：PHP 接收一串编号，服务器端渲染成条形码图片，页面能输出，打印机也能扫。这个 demo 不包含扫码识别，也不做复杂排版，核心是把字符串变成可扫描的图片。适合刚接触条码的 PHP 开发者，也适合在库存、图书、行政等模块里临时补一个条码能力的老手。能不能用、值不值得做，关键看两件事：码制选得对不对，生成过程是否可控。这两件正好是下面章节要拆开讲的东西。

很多搜索这个标题的人其实已经有了 PHP 环境，但不知道从哪个库开始，也不知道为什么网上的教程生成的条码扫不出来。这里先给一个反直觉结论：条形码生成里，图片能显示不算成功，能被扫描器稳定识别才算成功。所以后面的所有步骤，我都围绕"可扫描"这三个字来展开，而不是只贴一段能出图的代码。

2. 条形码生成技术选型：为什么用纯 PHP 库而不是 GD 手绘

2.1 码制先选对：Code128、EAN-13、Code39 的落地差异

条形码不是把文字直接画成黑白条纹，每一种码制都有自己的编码规则。同样是"ABC-12345"，用不同的码制生成出来的图案宽度、可容纳字符、扫描特性完全不同。实际业务里选错码制是最大的坑，甚至会让你后端的生成逻辑全部返工。

如果只做一个内部 demo，我一般建议直接选 Code128。理由是它信息密度高，同样的内容比 Code39 窄约一半，而且原生支持大写字母、小写字母、数字和符号，业务扩展时不用频繁换码制。物流面单、资产标签、订单编号这类场景基本都用它。Code39 的好处是宽容度高，部分老式扫描器和工业设备只认它，但代价是条码宽度大，内容一旦超过 20 位，打印标签会很吃力。

EAN-13 是最容易被误用的。它是零售商品条码，前 7 位左右其实包含了厂商识别代码，不是随便编一组 13 位数字就能用。如果你只是给公司内部物品打标签，完全没必要碰 EAN-13。如果是真实商品要进商超，那需要用企业申请到的前缀 + 商品代码，并让库生成校验位。很多初学者拿 Code128 生成了一个 13 位纯数字条码，扫码枪读出来也是一串数字，但对方的零售系统只认 EAN-13 的编码结构，所以会拒收。这个差异不在图片上，而在码制本身。

2.2 不推荐在 GD 画布上硬画条码的原因

网上有非常多"纯 GD 画条形码"的教程，思路是获取字符串长度，循环里用imagefilledrectangle在画布上交替画黑白竖线。这种代码跑起来很快，十行内就能出图，但它只能把字符简单地映射成竖线，不是真正的 Code128 编码。扫码枪读到的不是可见文字，而是黑白条的宽度比例。硬画的条码要么扫不出，要么只有运气好才能对上一次。

我见过一个模拟项目X的开发者，他自己用 GD 画了一个看起来很像条形码的图片，贴在页面上撑场面，等到真正用扫码枪验证的时候，识别率大概只有三四成。原因很直接：条形码每个字符由若干个模块组合，有起始符、终止符、校验符，还有条空的宽度比例，比如 Code128 里一个字符可能是 11 个模块，逻辑 1 和逻辑 0 的分配完全有规则。靠字符串长度去分配黑条数量，本质上和条码规则无关。

另一个现实问题是维护成本。纯 GD 硬画方案没有统一的 API，你今天给 Code128 画了一条竖线，明天换成 EAN-13 又得重算校验位，后天要输出 SVG 文件，又要重写一套渲染。而使用现成的纯 PHP 条码生成库，编码层和渲染层是拆开的，切换码制只是改一个常量，输出 PNG、SVG 也一样简单。所以我更倾向于把时间花在业务场景和参数调优上，而不是重新造条码规则。

2.3 安装前检查：确认 PHP 环境有 GD 扩展

PHP 生成条形码，最常见的输出是 PNG，而 PNG 渲染依赖 GD 扩展。很多 PHPer 平时不处理图片，本地环境根本没装 GD，到了项目交付时才处理，白页排半天。所以安装任何库之前，先在命令行确认环境状态：

php -v php -m | grep -i gd

这段命令的意思是：先确认 PHP 可用，再过滤模块列表里是否有 gd。如果输出里出现了gd，说明扩展已启用；如果没有任何输出，说明这个 PHP 环境还没有 GD。GD 不是只能用来生成条码，它也是imagecreatetruecolor、imagepng这些图片函数的基础。

在 Windows 上，需要去php.ini里把;extension=gd前面的分号去掉，然后重启服务；在 Linux 上一般要用系统包管理器安装对应 PHP 版本的 gd 扩展，安装后同样要重启 PHP-FPM 或 Apache。如果你完全动不了服务器，也有一个临时方案：改用 SVG 输出。同一套逻辑下，SVG 生成器不依赖 GD，代码改动很小，这一点后面章节会专门演示。

然后执行 composer 引入条码库。常见做法是安装一个 composer 开源包，包名我直接用比较稳定的那个纯 PHP 条码生成器：

composer require php-barcode-generator/php-barcode-generator

这个命令会在项目里创建vendor目录，并自动生成vendor/autoload.php入口文件。建议在项目根目录执行，避免路径混乱。如果服务器无法访问外网，需要先配置好 composer 镜像，或者把库源码手动放进vendor目录再引入入口文件，但手动方式要自行处理依赖，这里不多展开。

3. 从零跑通最小生成命令：第一个 PNG 条形码

3.1 一个文件输出到浏览器

最小可用的 demo 不需要表单，不需要数据库，一个 PHP 文件就够了。在项目根目录创建barcode.php，内容如下：

<?php require __DIR__ . '/vendor/autoload.php'; use Picqer\Barcode\BarcodeGeneratorPNG; $generator = new BarcodeGeneratorPNG(); $barcode = $generator->getBarcode( 'ABC-12345', // 要编码的内容 $generator::TYPE_CODE_128, // 码制常量 2, // 每个模块宽度，单位像素 60 // 条码高度，单位像素 ); header('Content-Type: image/png'); echo $barcode;

这里的逻辑是：实例化 PNG 生成器，调用getBarcode拿到一段 PNG 图片的二进制数据，然后通过header告诉浏览器这是图片，再echo出来。整个过程没有生成临时文件，输出直接进浏览器，叫接口式输出或流式输出都可以。

参数中新手指南最容易困惑的是第二个参数widthFactor。它不是图片整体宽度，而是条码里每个最小条空所占的像素数。Code128 的图案是由若干个宽窄不一的条空组合成的，widthFactor=2意味着一个基础模块是 2px。这个值设置成 1 时图片精细，但打印之后线条容易糊；设置成 2 或 3 时打印更稳定，但条码整体会变宽。高度 60px 适合贴在普通标签纸上，如果应用在物流面单，可以调到 80 到 100。

3.2 保存到文件：方便打印和后续归档

浏览器直接输出适合接口调试，但真实业务里更多时候要把条码保存成文件，再关联到商品记录里。保存文件其实只是把输出目标从浏览器换成一个目录：

<?php require __DIR__ . '/vendor/autoload.php'; use Picqer\Barcode\BarcodeGeneratorPNG; $generator = new BarcodeGeneratorPNG(); $barcode = $generator->getBarcode('ABC-12345', $generator::TYPE_CODE_128, 2, 60); $dir = __DIR__ . '/barcodes'; if (!is_dir($dir)) { mkdir($dir, 0755, true); } file_put_contents($dir . '/ABC-12345.png', $barcode); echo "saved";

保存前先检查目录是否存在，不存在就创建，然后直接写入文件。这里有一个容易踩的坑：如果文件名里带了斜杠、反斜杠或空格，file_put_contents会失败或者生成奇怪的文件名。真实项目里我会把内容做一次清洗，只保留字母、数字、连字符和下划线，商品编号里如果天然有/，也要一起替换掉。

和 3.1 的代码对比，这里的$barcode仍旧是同一份 PNG 二进制数据，只是没有header和echo，而是丢给了文件系统。这种方式在命令行下也完全可用，不会因为header输出而在 CLI 报错。

3.3 换码制：EAN-13 和 Code39 的最小改动

Code128 能覆盖大部分场景，但业务方如果明确要求 EAN-13，改起来也很小：

$generator = new BarcodeGeneratorPNG(); $barcode = $generator->getBarcode( '690123456789', // 12 位纯数字，库会自动补校验位 $generator::TYPE_EAN_13, // 换成 EAN-13 常量 2, 40 );

注意 EAN-13 的参数和 Code128 有一个关键差异：它只能放数字，而且长度必须是 12 位或 13 位。传 12 位数字时，库会按规则自动算出最后一位校验码；传 13 位数字时，库会校验最后一位是否正确，不正确就抛异常。很多第一次用的人传 8 位数字或者带字母，然后看到报错，以为库坏了，其实是对码制规则理解不到位。

Code39 的改法也类似，把常量换成TYPE_CODE_39即可。但 Code39 默认只支持大写字母和一部分符号，如果传入小写字母，部分实现会直接报错，部分会按不支持的字符处理。最稳妥的做法是先执行strtoupper()把内容转成大写，再用正则过滤掉不在表里的字符。

3.4 输出 SVG 避开 GD 依赖

有一些部署环境既没有 GD 扩展，也不允许临时安装。这时候不要卡死在 PNG 一条路上，可以把生成器换成 SVG 版本：

<?php require __DIR__ . '/vendor/autoload.php'; use Picqer\Barcode\BarcodeGeneratorSVG; $generator = new BarcodeGeneratorSVG(); $barcode = $generator->getBarcode( 'ABC-12345', $generator::TYPE_CODE_128, 2, 60 ); header('Content-Type: image/svg+xml'); echo $barcode;

这段代码和 3.1 几乎一样，只是类和header不同。SVG 是矢量图，打印出来不会发虚，缺点是个别老式浏览器不认，而且如果标签系统需要进一步用 GD 做后期合成，还得先把 SVG 转回位图，多一步转换成本。所以我的习惯是：本地开发优先 PNG，遇到环境没 GD 就用 SVG 临时顶上，同一个库内切换成本很低。

4. 完成一个完整交互 demo：表单选码制、即时生成、可打印

4.1 前端表单和 PHP 接收逻辑

把最小 demo 扩成能给别人演示的版本，需要一个简单页面：一个输入框、一个码制下拉框、一个生成按钮，图片生成后直接展示出来。我通常会把页面和生成接口拆成两个文件，页面负责收集参数，接口负责输出 PNG。

先写index.php，这部分是纯页面，不处理生成逻辑：

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>PHP 条形码生成 Demo</title> </head> <body> <h2>PHP 条形码生成工具</h2> <form action="barcode.php" method="get"> <label> 内容： <input type="text" name="text" value="ABC-12345" maxlength="32"> </label> <label> 码制： <select name="type"> <option value="code128">Code128</option> <option value="ean13">EAN-13</option> <option value="code39">Code39</option> </select> </label> <button type="submit">生成条形码</button> </form> </body> </html>

用 GET 而不是 POST，是为了让生成接口可以直接被<img>标签引用，也可以把 URL 发给别人调试。比如输入barcode.php?text=ABC-12345&type=code128就直接得到一张图片，这对后续打印和集成都方便。

然后是barcode.php，负责真正的生成。这里我把输入校验写得比较完整，避免用户传一个不支持的码制导致白屏或报错：

<?php require __DIR__ . '/vendor/autoload.php'; use Picqer\Barcode\BarcodeGeneratorPNG; $text = $_GET['text'] ?? 'ABC-12345'; $type = $_GET['type'] ?? 'code128'; $types = [ 'code128' => BarcodeGeneratorPNG::TYPE_CODE_128, 'ean13' => BarcodeGeneratorPNG::TYPE_EAN_13, 'code39' => BarcodeGeneratorPNG::TYPE_CODE_39, ]; if (!isset($types[$type])) { http_response_code(400); exit('不支持的码制'); } if ($text === '' || mb_strlen($text) > 64) { http_response_code(400); exit('内容长度不合法'); } if ($type === 'ean13' && !preg_match('/^\d{12}$|^\d{13}$/', $text)) { http_response_code(400); exit('EAN-13 需要 12 位或 13 位纯数字'); } if (preg_match('/[^\x20-\x7E]/', $text)) { http_response_code(400); exit('条形码内容仅支持可见 ASCII 字符'); } $generator = new BarcodeGeneratorPNG(); $barcode = $generator->getBarcode($text, $types[$type], 2, 50); header('Content-Type: image/png'); echo $barcode;

这里最值得讲的是白名单设计。我没有把$_GET['type']拼进代码或者直接传给生成器，而是先从映射表里取码制常量，取不到就返回 400。这样以后要增加新码制，只需要在$types里加一行。EAN-13 的正则校验放在生成前，避免库抛出难以理解的异常。最后那条 ASCII 校验是我在生产环境里吃过亏之后加上的，后面避坑章节会讲。

4.2 把条码以内嵌 base64 形式直接显示出来

有些场景不希望暴露一个独立的barcode.php接口，或者想在一个页面里生成多张条码，再统一打包打印。这时可以不走<img src="barcode.php">，而是在页面里直接用 base64 显示：

<?php require __DIR__ . '/vendor/autoload.php'; use Picqer\Barcode\BarcodeGeneratorPNG; $text = $_GET['text'] ?? 'ABC-12345'; $generator = new BarcodeGeneratorPNG(); $barcode = $generator->getBarcode($text, $generator::TYPE_CODE_128, 2, 50); $base64 = base64_encode($barcode); ?> <!DOCTYPE html> <html lang="zh-CN"> <body> <h2>生成结果</h2> <img src="data:image/png;base64,<?= $base64 ?>" alt="barcode"> </body> </html>

base64 内嵌的好处是当前页面自己生成自己显示，不依赖额外接口，也不容易因为 URL 参数过长导致浏览器截断。坏处是 base64 会让 HTML 体积增加约三分之一，如果页面里同时生成上百张条码，页面会非常大，这种场景就不适合内嵌，应该走保存文件或直接输出 PNG。

选择哪种方式判断标准很简单：低频、单张、临时演示用 base64；批量、打印、需要长期保存用文件方案。这个取舍在选型阶段就定下来，代码里不要两套混着写，否则后续维护很别扭。

4.3 给条码图片加上底部可读文字

实际标签上除了条码，通常还要在下方显示一串人能读懂的编号。默认生成的 PNG 只有条空，没有文字，所以需要把条码图片再合成到一张更大的画布上。这个步骤依赖 GD 的图片合并能力，代码核心就是先解码条码图，再画白底画布，最后把条码贴上去，在最底部写文本：

<?php require __DIR__ . '/vendor/autoload.php'; use Picqer\Barcode\BarcodeGeneratorPNG; $generator = new BarcodeGeneratorPNG(); $text = 'ABC-12345'; $barcode = $generator->getBarcode($text, $generator::TYPE_CODE_128, 2, 50); $barcodeImg = imagecreatefromstring($barcode); $imgWidth = imagesx($barcodeImg); $imgHeight = imagesy($barcodeImg); $labelHeight = 20; $canvas = imagecreatetruecolor($imgWidth, $imgHeight + $labelHeight); $white = imagecolorallocate($canvas, 255, 255, 255); imagefilledrectangle($canvas, 0, 0, $imgWidth, $imgHeight + $labelHeight, $white); imagecopy($canvas, $barcodeImg, 0, 0, 0, 0, $imgWidth, $imgHeight); $black = imagecolorallocate($canvas, 0, 0, 0); $font = 5; $textWidth = strlen($text) * imagefontwidth($font); $x = max(2, intval(($imgWidth - $textWidth) / 2)); imagestring($canvas, $font, $x, $imgHeight + 2, $text, $black); header('Content-Type: image/png'); imagepng($canvas); imagedestroy($canvas); imagedestroy($barcodeImg);

这段代码里，imagecreatefromstring把$barcode二进制转成 GD 位图资源，这是合成的基础。然后创建一张比原图高 20px 的新画布，用白色填充，把原条码放在顶部，底部留给文字。imagestring是 GD 内置字体函数，第 5 号字体是等宽点阵字体，所以可以用strlen * imagefontwidth(5)计算出文字像素宽度，实现粗略居中。

这段方案有一个明显边界：内置字体不支持中文，中文会显示成乱码。如果标签下方要显示中文名称，必须用imagettftext并指定一个包含中文字形的 ttf 字体文件，同时还要考虑字体路径在不同服务器上不一致的问题。我的做法是把字体文件放在项目私有目录，不依赖系统字体，这样迁移环境时不容易翻车。

5. php 生成条形码常见问题排查：扫不出、白页和乱码的避坑记录

5.1 扫描器读不出来：对比度不足比尺寸更常见

现象：条码图片在浏览器里看着很清晰，但用扫码枪或者手机多次扫描都失败，或者只有某个角度扫得出来。

原因：最常见的是颜色对比度不达标。条码扫描依赖深色条对光的吸收和浅色空白对光的反射，如果条码用了深灰色、深蓝色，或者背景不是纯白而是浅黄、透明 PNG，都会降低信噪比。另一个常见原因是widthFactor设置成 1，打印之后墨迹扩散，细条之间发生粘连，扫描器没法分辨模块边界。第三个原因是在页面里用 CSS 对<img>做了拉伸，改变了条空的宽高比例。

解决：先保证条码颜色使用纯黑（0,0,0），背景用纯白（255,255,255）。然后把widthFactor至少设成 2，并给条码四周留出 10px 以上的白边，这在印刷上叫静区，很多新手漏掉。如果图片已经在页面上被拉伸，检查 CSS 里是否写了类似width: 100%或object-fit的属性，按原始宽高比展示。遇到打印标签，最好导出 PNG 后在本地预览一遍，确认线条没有糊。

5.2 EAN-13 校验位报错，甚至生成的码扫出来是空

现象：调用getBarcode时抛出异常，类似提示InvalidArgumentException；或者代码不报错，但扫码后得到的数字和输入不一致。

原因：EAN-13 不是简单的 13 位数字拼接。它的最后一位是校验位，由前 12 位按固定权重计算得出。库支持两种用法：传 12 位纯数字，自动补校验位；传 13 位纯数字，校验最后一位是否正确，不正确就抛异常。很多开发者传了不足 12 位的数据，或者传了包含字母的内容，自然进不了 EAN-13 的编码流程。

解决：把输入统一规范化。前端限制input只能输入数字，后端再做一次正则校验：preg_match('/^\d{12}$|^\d{13}$/', $text)。如果用户录入的是 11 位或 8 位数字，不要试着补齐，直接提示错误。我在某个项目里曾经自己写校验位算法，权重用错了导致供应商扫码后报错，后来改成统一传 12 位给库处理，问题消失。这个教训让我明白：既然库已经实现了校验逻辑，项目里就不要重复造轮子。

5.3 GD 扩展缺失导致空白页

现象：访问barcode.php页面完全白屏，命令行运行同一脚本时报错，常见提示是Call to undefined function imagecreatefromstring()。

原因：PNG 生成器依赖 GD 扩展，而很多精简版 PHP 环境默认没有装。浏览器里直接白屏是因为 PHP 配置关闭了错误显示，错误被写进日志，用户只看到空白页。

解决：第一步确认是不是 GD 的问题，在命令行执行php -m | grep -i gd。如果没输出，可以用系统包管理器安装你当前 PHP 版本对应的 gd 扩展并重启服务。如果服务器环境没有权限安装，临时方案是切换到 SVG 生成器，把BarcodeGeneratorPNG换成BarcodeGeneratorSVG，输出格式改成image/svg+xml，代码结构完全一致。SVG 方案不依赖 GD，但后续如果用 GD 做文字合成，又得转成位图，所以它只能算应急手段，不能根治。

5.4 PNG 输出乱码或图片损坏

现象：访问barcode.php时浏览器显示一串乱码字符，或者显示"图像格式错误"，有时候图片只显示一半。

原因：输出 PNG 前，PHP 已经向浏览器输出了其他内容。比如文件开头有 BOM、有空行，或者barcode.php里引入了某个视图文件，视图中的 HTML 先于header('Content-Type: image/png')输出到了缓冲区，导致浏览器收到的是一半 PNG 一半 HTML。

解决：把生成接口写干净，文件开头不要有?>后的多余空行，也不要在header之前输出任何调试信息。如果项目框架自带输出缓冲，可以在header前执行ob_clean()清空之前内容，但要注意有些全局缓冲会被误伤。我最常遇到的情况是同事在调试时加了一句echo 'start';然后忘了删，排查时直接搜索barcode.php里的所有echo和文件头两侧的空格，基本上十秒定位。

5.5 中文内容生成的条码扫码乱码

现象：输入中文商品名，条码能正常生成，扫码后出来的是类似%E4%B8%AD%E6%96%87的字符，或者干脆扫不出。

原因：常见条码码制本质上只能编码 ASCII 可见字符，中文在 UTF-8 下占多个字节，库按字节编码，扫描器默认按 ASCII 解码，于是字节变成了%之类的符号。不是图片生成错了，而是条码这种介质不适合直接承载中文。

解决：产品层面明确条码内容是编号、单号这类 ASCII 字符串，中文名称放到底部用 GD 文字绘制，而不是放进条码里。如果一定要在条码中存中文，需要先约定编码方式，比如 URL 编码后生成，扫码后再解码，但这会改变条码长度且部分扫码设备不支持。在 demo 阶段，我在barcode.php里加了 ASCII 正则校验，直接把非 ASCII 字符拦在外层，反而减少了大量后续解释成本。

6. 进阶：批量生成和验证条形码是否合格

6.1 批量生成：循环保存到目录

实际业务里很少只生成一张，更多是每月给一批新品编号生成标签。这时候把生成逻辑包成一个循环，保存到统一目录：

<?php require __DIR__ . '/vendor/autoload.php'; use Picqer\Barcode\BarcodeGeneratorPNG; $codes = ['A001', 'A002', 'B001', 'B002']; $dir = __DIR__ . '/output'; if (!is_dir($dir)) { mkdir($dir, 0755, true); } $generator = new BarcodeGeneratorPNG(); foreach ($codes as $code) { $filename = preg_replace('/[^\w\-]+/', '_', $code) . '.png'; $barcode = $generator->getBarcode($code, $generator::TYPE_CODE_128, 2, 50); file_put_contents($dir . '/' . $filename, $barcode); }

这个循环里有两个容易忽略的点。第一，preg_replace做文件名清洗，把斜杠、空格、中文全部替换成下划线，避免生成非法路径。第二，批量生成时复用同一个$generator对象，不要每张都 new，这样能省掉一部分重复初始化开销。如果一次生成上万个文件，建议把生成和写文件拆成两个阶段，先确认数据合法性，再写入磁盘，避免生成到一半发现第三条数据抛异常，前面文件全成了孤儿文件。这不算高并发，但真实场景里更稳。

6.2 验证条码是否合格的两个实用做法

生成完不能只看图片，至少要验证一次内容能被正确识别。最直接的办法是找一把扫码枪或带扫码功能的设备扫一下，读出结果和输入做对比。没有扫码枪时，可以在屏幕上打开生成的 PNG，用手机自带相机或扫码工具扫，注意屏幕反光会影响识别率，角度稍微倾斜一下再试。

另一个不依赖硬件的办法是在测试脚本里检查文件头和图片尺寸。PNG 文件头固定是89 50 4E 47，也就是常见的PNG四个字节，检查它可以确认文件不是空文件。然后通过getimagesize拿到图片宽度和高度，如果高度小于预设值，说明生成参数有问题。这些检查无法判断条码是否符合编码规则，但能快速过滤掉明显失败的文件，省的每一张都拿扫码枪扫。

6.3 我的习惯和收尾

每次做这类 demo，我都会把码制白名单、输入长度限制、字符集限制固定在一个配置文件而不是散布在业务代码里。这样即使团队里换了人，也不会出现有人在代码里加一行"允许小写字母"导致条码突然扫不出的情况。曾经有一位同事为了图省事，把生成内容从商品编号换成了商品中文名，生成没报错，但扫码系统全乱，排查半天才发现是字符集问题。那之后我坚持在接口入口统一校验并写清楚测试用例，宁可多写几行正则，也不给后续埋坑。

你如果只是想让这个 demo 跑起来，我的建议是先用 Code128 + 英文数字 + PNG 保存到文件这一条链路，它最稳、最不容易出意外。等业务场景明确了，再扩展到 EAN-13 校验和 SVG 输出。方向本身值得投入，但不要一上来就支持所有码制和所有字符集。希望帮到你。

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