一个房产中介的PDF难题，逼我手写像素级图像合成

用三行CSS就能搞定的事，有人花了三天写底层算法。不是炫技，是被逼的。

45分钟 vs 一键生成

一位房产中介找到作者时，带着一个老问题。每份房产推介书——那种发给潜在买家的多页 glossy PDF——全靠手工在Adobe排版工具里拼装。地址手动输入，价格手动输入，照片一张张导入，平面图附在后面，Logo摆好，免责声明贴上，导出PDF，存到某处，发送。

每套房源耗时45分钟。价格一变，从头再来。

这家中介已经在用WordPress，JetEngine（一种WordPress插件）已经把房源管成了自定义文章类型。路径很清晰：直接从数据生成推介书——一键一点，一份PDF，像素级还原企业设计。

插件的前80%很顺。PHP、Dompdf（一个PHP库，用于将HTML转为PDF）、HTML模板、FPDI（用于合并PDF的PHP库）来拼入平面图PDF。一周搞定。

最后20%差点把人搞垮。

三行CSS的噩梦

推介书封面是那种经典房产风格：房源主图打底，上面压一层深色渐变，让标题能看清。

CSS里三行代码：

.cover {
background-image: url(...);
background-blend-mode: multiply;
}
.overlay {
opacity: 0.6;
background: linear-gradient(...);
}

到了Dompdf里，background-blend-mode和opacity都不靠谱。不同Dompdf版本、不同字体、不同纸型，渲染结果五花八门。作者试了三个小时的各种组合，最终承认：这条路走不通。

换库？mPDF？wkhtmltopdf？Browserless？

这些都有额外的运营负担：wkhtmltopdf是个二进制文件，得在主机上安装更新；Browserless是外部服务；mPDF意味着重写模板层。

中介要的是能在标准WordPress主机上部署的方案。不要二进制。不要外部服务。不要黑箱。

于是作者走了另一条路。

像素级硬算

如果Dompdf不能在渲染时做混合，那混合就得在Dompdf看到图片之前完成。也就是说，用PHP的GD库（图像处理库），一个像素一个像素地算。

代码不长，但全是暴力数学：分辨率的两倍 × 双通道 × 每个像素。时间复杂度O(n²)。

// 对两张同尺寸图片做正片叠底混合
function multiply_blend($base, $overlay) {
$width = imagesx($base);
$height = imagesy($base);

for ($y = 0; $y < $height; $y++) {
for ($x = 0; $x < $width; $x++) {
$b = imagecolorat($base, $x, $y);
$o = imagecolorat($overlay, $x, $y);

// 逐通道正片叠底公式：(a × b) / 255
$r = (($b >> 16 & 0xFF) * ($o >> 16 & 0xFF)) / 255;
$g = (($b >> 8 & 0xFF) * ($o >> 8 & 0xFF)) / 255;
$bl = (($b & 0xFF) * ($o & 0xFF)) / 255;

$color = imagecolorallocate($base, $r, $g, $bl);
imagesetpixel($base, $x, $y, $color);
}
}
return $base;
}

没有GPU加速，没有SIMD优化，纯PHP循环。一张2000×1500的封面图，意味着900万次像素操作，2700万次通道计算。

但它在任何标准PHP主机上都能跑。不依赖外部服务，不挑环境。

为什么这件事值得说

这不是一个"用C重写提升性能"的技术故事。这是一个关于约束条件的商业决策。

作者本可以选更优雅的方案：容器化部署wkhtmltopdf，或者接入Browserless的API。但那样会增加运维复杂度——谁来管二进制更新？外部服务挂了怎么办？客户的主机权限能不能装东西？

房产中介的核心需求是"一键生成PDF"，不是"维护一套PDF生成基础设施"。

手写像素算法看起来是技术倒退，实则是把复杂度收拢到可控范围。GD库是PHP标准扩展，99%的主机都开着。代码自包含，不依赖网络，不依赖特定版本。

这种选择在企业软件里其实很常见。Slack早期用Electron被骂性能差，但换来的是跨平台一致性和快速迭代。Notion的编辑器被吐槽慢，但协同能力让它站稳了脚跟。技术选型从来不是选"最好"的，是选"最符合约束"的。

这个案例的特殊之处在于极端程度——为了绕过Dompdf的渲染缺陷，直接下沉到像素操作层。相当于为了修一扇门，重学了木工。

给你的启发

如果你也在做B端工具，遇到类似困境：现有库有缺陷，换库成本高，自研又太重——不妨想想这个案例的解题思路。

不是"怎么写更优雅的代码"，是"客户的真实约束是什么"。

标准主机环境、零运维负担、一键部署——这些才是房产中介愿意付钱的东西。45分钟手工排版变成3秒自动生成，这个价值差足够覆盖像素级算法的开发成本。

下次遇到"这个库不支持"的绝境，别急着换栈。先画清楚约束条件的边界，答案可能藏在更底层的地方。