Laravel-Snappy 在 CentOS 服务器上处理大文件 PDF 生成问题的解决方案

问题背景

在使用 Laravel-Snappy 进行 PDF 生成时，开发人员可能会遇到一个特定于 Linux 环境的问题：当处理大型 PDF 文件（超过 800 页）时，系统会抛出 ProcessSignaledException 异常，显示"进程收到信号 11"的错误。这个问题在 Windows 环境下不会出现，但在 CentOS 服务器上会稳定复现。

信号 11 错误的本质

信号 11（SIGSEGV）通常表示进程尝试访问了它没有权限访问的内存区域，也就是所谓的"段错误"。在 PDF 生成过程中出现这种错误，通常与以下几个因素有关：

1. 内存限制：生成大型 PDF 需要较多内存资源
2. 系统资源限制：Linux 系统对进程的资源限制
3. wkhtmltopdf 本身的问题：这个底层工具在处理复杂 HTML 时可能存在内存泄漏

具体问题分析

从开发人员提供的代码和错误信息来看，问题主要出现在以下几个方面：

1. HTML 内容复杂度：生成的 PDF 页数超过 800 页后出现问题
2. JavaScript 执行：在页眉中使用了动态 JavaScript 来显示页码和日期
3. 系统环境差异：Windows 和 CentOS 环境下表现不一致

解决方案

1. 优化 HTML 和 JavaScript

开发人员最终发现问题的根源在于全局页眉中的 JavaScript 代码。特别是以下两部分：

// 日期和时间显示脚本
var date = new Date();
var time = date.toLocaleTimeString();
var formattedDate = date.toDateString().split(' ').slice(1).join('-');
document.write(formattedDate + ', ' + time);

// 页码显示脚本
var vars = {};
var x = document.location.search.substring(1).split('&');
for (var i in x) {
    var z = x[i].split('=', 2);
    vars[z[0]] = unescape(z[1]);
}
document.write('Page ' + vars['page'] + ' of ' + vars['topage']);

这些脚本在每一页都会被解析和执行，当页数很多时，会导致内存消耗急剧增加。

优化建议：

• 使用静态内容替代动态 JavaScript
• 使用 wkhtmltopdf 内置的页眉页脚变量功能
• 将复杂的计算逻辑移到 PHP 端处理

2. 调整系统配置

对于必须处理大型 PDF 的场景，可以调整以下系统配置：

1. 增加 PHP 内存限制：

   memory_limit = 512M  # 或更高
   

2. 调整进程超时设置：

   $pdf->setTimeout(3600);  // 设置为足够大的值
   

3. 优化 wkhtmltopdf 参数：

   $pdf->setOption('javascript-delay', 5000);
   $pdf->setOption('no-stop-slow-scripts', true);
   

3. 分块处理策略

对于超大型 PDF，可以考虑以下分块处理策略：

1. 分段生成：将内容分成多个部分分别生成 PDF，然后合并
2. 分批处理：对数据进行分页处理，避免一次性加载所有数据
3. 使用更高效的 PDF 生成工具：如 TCPDF 或 Dompdf 处理基础内容

最佳实践建议

1. 环境一致性：确保开发、测试和生产环境使用相同版本的 wkhtmltopdf
2. 性能监控：对大文件生成过程进行资源使用监控
3. 错误处理：实现完善的错误捕获和重试机制
4. 日志记录：详细记录生成过程中的关键指标和错误信息

总结

Laravel-Snappy 在 Linux 环境下处理大型 PDF 时出现信号 11 错误，主要是由于资源限制和 JavaScript 执行问题导致的。通过优化 HTML 内容、调整系统配置和采用分块处理策略，可以有效解决这一问题。对于需要生成超大型 PDF 的应用，建议预先进行充分的性能测试和资源规划。