TP6.0仅提供Web框架能力,电子合同需依赖外部工具链实现;PDF生成推荐tcpdf(适合结构化合同)或dompdf(适合HTML直转);真水印须矢量绘制并锁定图层;法律有效签名需PKCS#7数字签名而非图片图章。
TP6.0 本身不提供电子合同核心能力,它只是 Web 框架;真正实现电子合同必须靠外部工具链组合,且「签名」和「法律效力」是两回事——TP6.0 能做的只是生成带水印的 PDF 文件,不能替代 CA 认证、时间戳、哈希存证等合规环节。
tcpdf 还是 dompdf?两者在 TP6.0 中都可集成,但适用场景差异明显:
tcpdf:原生支持中文、字体嵌入稳定、可直接写二进制流,适合需要精确控制页眉页脚、多语言混排、加签区域预留的合同场景;缺点是文档陈旧、部分新 CSS 不支持dompdf:依赖 PHP 的 DOM 扩展,渲染更接近浏览器,适合 HTML 模板直接转 PDF;但中文断行易出错,字体需手动注册,生成大文件时内存占用高tcpdf;若只是把前端渲染好的合同页“截图式”导出,dompdf 更快上手水印不是简单叠一层半透明文字——tcpdf 的 addPageTemplate() + setWatermarkText() 只是视觉干扰,导出为图片或复制文本后即失效。真要防篡改,得在每页底层绘制矢量文字并锁定图层:
startPageGroup() 后用 setTextRenderingMode(2)(填充+描边),让水印文字无法被 PDF 阅读器选中-30 度、透明度 0.1、字体用 helvetica(避免中文字体嵌入失败导致空白)addPage() 之后、内容写入之前插入,否则会被正文覆盖或裁切用户上传的签名 PNG/JPG 图片直接 Image() 插入 PDF,法律上属于“可视化标记”,不是电子签名。若要满足《电子签名法》要求,必须:
openssl_sign() 对合同原文 SHA256 哈希值做 RSA 签名,存入数据库 sign_hash 和 sign_pubkey
setSignature()(tcpdf 支持)嵌入符合 PKCS#7 标准的数字签名,但需提前配置 CA 证书路径,且浏览器打开时才会显示「已验证签名」绿标file_put_contents('contract.pdf', $pdf->Output('S')) 直接保存未签名文件;正确做法是先生成原始 PDF,再用 tcpdf 的 setSignature() 注入签名,最后输出水印位置偏移、字体缺失报错、签名后 PDF 打不开……这些问题背后往往是 PDF 规范版本(1.4 / 1.7)和阅读器兼容性在起作用,而不是 TP6.0 的问题。别在框架层找答案,得盯住生成器本身的参数和输出流程。