Dompdf无法渲染INR符号：本地正常服务器显示问号求助

我之前也踩过dompdf渲染INR符号在生产环境变问号的坑，给你几个亲测有效的排查和解决方向：

1. 先确认生产服务器的字体文件是否到位 #

本地能用DejaVu Sans，大概率是生产环境没把字体部署对：

• 检查@font-face里写的字体路径在服务器上真实存在，比如本地是./fonts/DejaVuSans.ttf，要确认服务器上对应目录下有这个文件
• 给字体文件设置正确的权限，比如chmod 644 /path/to/fonts/DejaVuSans.ttf，确保服务器进程能读取它
• 可以直接在服务器终端跑个命令验证路径：ls /your/font/path/DejaVuSans.ttf，看能不能找到文件

2. 强制PDF内容使用DejaVu Sans #

有时候dompdf会偷偷 fallback 到系统默认字体，得明确指定：

• 在HTML的全局样式里设置：

  body {
    font-family: 'DejaVu Sans', sans-serif !important;
  }
  

• 或者专门给INR符号的元素加样式：

  .currency-inr {
    font-family: 'DejaVu Sans', sans-serif;
  }
  

3. 清掉dompdf的字体缓存 #

dompdf会生成字体缓存文件，生产环境可能缓存了旧的无效数据：

• 找到dompdf的缓存目录（一般在dompdf/lib/fonts/下），删掉所有和DejaVu Sans相关的.ufm或.php缓存文件
• 之后重新生成PDF，让dompdf重新加载字体生成新缓存

4. 确认DOMPDF_UNICODE_ENABLED的设置时机 #

这个常量一定要在实例化dompdf对象之前定义，不然根本没用：

// 先定义配置
define("DOMPDF_UNICODE_ENABLED", true);
// 再加载类和实例化
require_once 'class-my-pdf-creator.php';
$dompdf = new my_pdf_obj();
// 后续渲染代码

5. 强制dompdf嵌入字体到PDF #

让字体直接打包进PDF，不依赖服务器系统字体：

• 在@font-face里确保路径正确，同时开启dompdf的字体嵌入选项：

  $dompdf->set_option('isFontSubsettingEnabled', true);
  

  这样生成的PDF会把用到的字体部分嵌入，避免环境差异导致的显示问题

6. 检查版本兼容性 #

如果本地和生产的dompdf或PHP版本不一样，也可能出问题：

• 确认生产环境的PHP版本符合dompdf的要求（比如dompdf 2.x需要PHP 7.1及以上）
• 尽量让本地和生产用相同版本的dompdf，避免版本差异带来的奇怪bug

内容的提问来源于stack exchange，提问作者teejay