Odoo QWeb PDF报表添加自定义页眉图片异常的问题排查
异常根因说明
- 原代码逻辑:
<img t-if="o.company_id.header" t-att-src="'data:image/png;base64,%s' % to_text(o.company_id.header)" style="max-width: 100%;"/>核心是从数据库读取当前公司配置的页眉logo,转成内嵌base64格式的图片源,图片内容直接嵌入HTML代码,无需额外发起HTTP请求拉取资源,导出PDF时不会受网络、鉴权规则影响。 - 破图小方框的核心触发原因:Odoo导出PDF依赖wkhtmltopdf渲染引擎,引擎加载外部资源时严格遵循HTTP请求规则:
- 硬编码相对路径
/mymodule/static/src/img/header2.jpg会被引擎识别为需要Web端鉴权校验的资源请求,而wkhtmltopdf的导出流程没有携带Web端登录态Cookie,无法获取真实图片文件,最终渲染为破图占位框 - 测试时可正常显示的系统内置header.jpg,是因为这类核心静态资源已经在Odoo路由配置中开放无鉴权访问权限,请求不会被拦截
- 硬编码相对路径
- 清缓存、重启服务、升级模块的操作无法解决问题,本质是故障不在缓存层面,属于资源加载的鉴权规则不匹配。
可落地解决方案
方案1:使用内置静态资源路由过滤器(和系统逻辑兼容,维护成本最低)
不要硬编码相对路径,调用报表模板内置的url_for过滤器,为静态资源自动拼接可被wkhtmltopdf直接访问的无鉴权路由前缀,修改img代码为:
<img t-att-src="'/mymodule/static/src/img/header2.jpg' | url_for" style="max-width: 100%;"/>
方案2:图片转base64内嵌(稳定性最高,无加载失败风险)
对齐原公司logo的加载逻辑,彻底绕开HTTP请求环节:
- 将本地
header2.jpg转换为base64编码字符串 - 直接将编码内容写入img标签的src属性,格式为:
<img src="data:image/jpeg;base64,替换为你的完整base64编码内容" style="max-width: 100%;"/>
基础排查项
- 确认文件名大小写完全匹配:Linux服务器环境对文件名大小写敏感,代码中写的路径和实际文件名大小写不一致会直接触发找不到文件的错误
- 确认文件存放位置正确:检查自定义模块的
static/src/img/目录下,是否存在目标图片文件,避免出现文件漏放、目录层级错误的问题。
内容的提问来源于stack exchange,提问作者Mk Sorbet
相关产品推荐
相关产品推荐

