php生成pdf需依赖tcpdf、mpdf、dompdf等外部库；tcpdf需显式加载中文字体并避免writehtml；mpdf仅支持部分css2.1属性；dompdf处理大表格易内存溢出；导出时须严格控制http头与输出缓冲。
PHP 本身不内置 PDF 生产能力，直接用 echo 输出 PDF 二进制或靠浏览器渲染 HTML 为 PDF 都不可靠——真要稳定生成 PDF，得依赖外部库，而 tcpdf、mpdf、dompdf 是目前最常被选中的三个，它们定位和适用场景差异明显，选错就容易卡在中文乱码、分页错位、CSS 不生效这些地方。
为什么 tcpdf 生成中文经常是方块或空白
tcpdf 默认字体不支持 UTF-8 中文，即使你用了 setLanguageArray() 或设置了 mb_internal_encoding('UTF-8')，只要没显式加载中文字体，文本照样渲染失败。
- 必须用
addTTFfont()提前注册一个支持中文的 TrueType 字体（如simhei.ttf或msyh.ttc），再通过setFont()切换过去 - 字体文件路径需为服务器绝对路径，相对路径在 CLI 模式下大概率失效
- 别用
writeHTML()直接塞含中文的 HTML —— 它对内联样式和自定义字体的支持弱，优先改用Cell()、MultiCell()等原生方法写入文本 - 若坚持用 HTML 渲染，得配合
setHtmlVSpace()和setRTL()调整行高与方向，否则中文段落会挤在一起
mpdf 里 CSS margin/padding 不生效的常见原因
mpdf 对 CSS 的支持比 tcpdf 强，但不是全兼容。比如 margin-top: auto、display: grid、position: sticky 这些现代属性它压根不认。
- 只认部分 CSS2.1 属性，
flex布局基本无效，表格布局更稳 -
@media print规则会被忽略，响应式写法在这里没意义 - 外边距折叠（margin collapse）行为和浏览器不一致，建议统一用
padding控制内部间距，margin只用于模块间隔离 - 如果用了
autoScriptToLang或useSubstitutions，某些字体替换逻辑会干扰盒模型计算，关掉试试
dompdf 渲染大表格时内存溢出或超时
dompdf 是纯 PHP 实现，解析 HTML + CSS + 渲染三步都在内存里完成，遇到几百行带样式表格很容易撑爆 memory_limit 或触发 max_execution_time。
- 把大表格拆成多个
<table>，每 30–50 行一组，中间用空 <code><div style="page-break-inside: avoid"></div>隔开 - 禁用
DOMPDF_ENABLE_CSS_FLOAT（默认开启），浮动元素是性能黑洞 - 避免在
<td> 里嵌套多层 <code><div>，用 <code>border-collapse: collapse替代边框模拟 - 生成前调用
ini_set('memory_limit', '512M')和set_time_limit(300)，但治标不治本，关键还是精简 HTML 结构 - 必须在
Output()或stream()前清空所有输出缓冲：ob_end_clean()，不能只靠ob_flush() - 响应头顺序很重要：先
Content-Type: application/pdf，再Content-Disposition: attachment; filename="xxx.pdf"，最后才是Content-Length - 如果用了框架（如 Laravel、ThinkPHP），确保没在 PDF 生成前触发日志写入、调试信息输出或自动 JSON 化响应
- 开发时用
file_put_contents('debug.pdf', $pdf->Output('S'))先保存到磁盘验证内容是否正常，再排查传输链路
导出 PDF 时浏览器下载失败或文件损坏
不是库的问题，90% 出在 HTTP 响应头或输出缓冲控制不当。
PDF 生成从来不是“调个函数就完事”的事——字体、CSS、内存、HTTP 头，每个环节都可能静默失败。最稳妥的做法，是先用最小 HTML + 最简样式跑通流程，再逐项加功能，而不是一上来就塞满业务数据和复杂样式。
