广告里的字符串消失事件:AppLovin VAST 宏替换与表达式语法的正面交锋

某次线上排查，发现通过 AppLovin 渠道投放的广告，App 标题、落地页 URL 全是空的。

打开 DSL，表达式写的清清楚楚：${adInfo.app.title}、${adInfo.open.landingPageUrl}。在非 AppLovin 渠道测，渲染完全正常——渲染引擎求值、填充、上屏，一切如丝般顺滑。但换到 AppLovin，渲染引擎拿到的值在数据到达之前就已经消失了。

定位到根本原因之后，我们发现这是一个涉及 VAST 标准、广告投放链路、以及前端模板引擎语法的三方撞车。

广告的下发链路比你想象的更长

在讲 Bug 之前，先说一下商业广告投放里，一次展示背后到底经历了什么。

一次广告请求的链路大体是：媒体 App 发起请求 → SSP（需求方平台）竞价 → AppLovin SDK 赢得请求 → 从 DSP / 广告主侧拉取素材。AppLovin 使用 VAST 协议作为视频广告的交换格式——VAST 里有一个关键标签：<HTMLResource>，素材可以是一段完整的 HTML，直接在 SDK 里渲染。

我们的广告创意就是走这条路下发的：后端把 DSL JSON 注入到一个 HTML 模板里，这个 HTML 被塞进 VAST 的 <HTMLResource>，AppLovin SDK 取到后交给渲染引擎执行。

VAST 这个格式本身有一个宏替换机制——${CLICK_URL}、${TIMESTAMP} 这类标准宏，AppLovin 在解析 VAST 时会统一替换成真实值，这是协议规定的正常行为，是广告投放链路里各方都依赖的功能。

问题在于：我们 DSL 的模板表达式语法也是 ${expr} 格式。

两种撞车结果，都很糟糕

AppLovin 的宏处理器不认识 ${adInfo.app.title} 这种业务表达式，但它认识 ${ 这个格式。实测中，它的处理行为有两种，且不稳定、均有发生：

第一种还算"手下留情"——渲染引擎现有的 replaceBareExpr 安全网，对 {identifierPath} 格式的简单路径表达式还有部分恢复能力。第二种彻底无解，渲染引擎拿到的已经是空字符串，没有任何信息可以恢复。

两种情况都会造成广告渲染异常：App 名显示空、落地页跳转失效。这不是小问题——落地页 URL 丢了意味着用户点击广告后什么也不会发生，对投放效果的伤害是直接的。

两条看似合理的路，都走不通

既然问题出在 ${ 这个字符序列被 AppLovin 识别，直觉上有两个修法：

方案一：HTML 实体编码

把 $ 编码成 HTML 实体 $，让 DSL JSON 里不出现裸的 ${：

"${adInfo.app.title}"

看起来很聪明——${ 不是 ${，AppLovin 应该不认识它。

但实测失败了。VAST 本身是 XML 格式，<HTMLResource> 的内容在 XML 解析阶段就会经历标准的 HTML 实体解码——$ 被还原成 $ 是 XML 解析器的内置行为，不需要 AppLovin 额外做什么。解码之后 ${adInfo.app.title} 原样出现在宏处理器面前，照样被替换。白忙活一场。

方案二：对整个 ad-context 做 Base64 编码

把整个 DSL JSON Base64 编码后塞进 HTML，AppLovin 不可能识别 Base64 字符串里的宏模式。防御性最强——不止防 ${，任何宏格式都绕不过去。

代价是体积。Base64 的原理是每 3 字节映射成 4 个 ASCII 字符，原始体积必然增加 33%，这是数学决定的，没有例外。

“那 gzip 压回来不就好了？”——这个直觉是错的，用项目里实际的 DSL 模板测一次就清楚了：

测试样本（典型 DSL 模板）：  文件        原始     gzip原始   Base64    gzip-B64   gzip-B64 / gzip原始 模板 A     5490B     989B      7320B      1657B         +67.5% 模板 B     8273B    1322B     11032B      2335B         +76.6% 模板 C      891B     394B      1188B       575B         +46.0% 模板 D     4261B     917B      5684B      1487B         +62.2%

gzip 压缩的原理是找重复的字节序列。原始 JSON 里有大量重复的 key（adInfo、visibility、style……），gzip 压得极狠，压缩率能到原始体积的 16–44%。Base64 之后，这些重复模式被分散到了 3 字节对齐的 chunk 里，gzip 找到的重复序列变少——虽然也能压，但效率明显更差。

结果是：Base64 + gzip 的最终体积是 raw + gzip 的 1.5–1.8 倍，差距不会因为 gzip 消失，反而在 DSL 越复杂时越明显。

加上改动链条长、涉及 template.html 模板格式 + 渲染引擎 decode 逻辑 + 后端注入逻辑全部联动，任何一环出问题都可能导致全量广告白屏——风险高、成本高、体积也真的更大。

两条路都堵死之后，解法反而简单起来了。

真正有效的方案：只转义关键的两个字符

AppLovin 宏处理器识别的是 ${ 这个两字符序列。只要 VAST HTML 里不出现这两个字符连在一起，问题就解了——但 DSL 存储格式完全不用动。

方案原理如下：

btoa('${') 的值是 JHs=，这是一个固定值，无歧义。后端在把 DSL JSON 注入 VAST HTML 之前，只做一次替换：

const dslJson = JSON.stringify(styleDSL).replace(/\$\{/g, 'JHs=');// 注入 VAST HTML 时使用 dslJson

${adInfo.app.title} 就变成了 JHs=adInfo.app.title}——AppLovin 的宏处理器看到这串字符，不匹配任何宏模式，直接忽略，原样透传。

渲染引擎的 filter.ts 在求值前先做一步 decode，把 JHs= 还原为 ${，然后走原有的 replaceDollarExpr 逻辑求值：

const VAST_DOLLAR_BRACE_ESCAPE = 'JHs='; // btoa('${') 的固定值  function decodeVastEscape(s: string): string {   return s.includes(VAST_DOLLAR_BRACE_ESCAPE)     ? s.replace(/JHs=/g, '${')     : s; }  export const filter = (tpl, data, ...rest) => {   if (typeof tpl !== 'string') return tpl;   let result = decodeVastEscape(tpl);          // ① 新增：还原转义   result = replaceDollarExpr(result, data);    // ② 原有：主路径求值   result = replaceBareExpr(result, data);      // ③ 原有：安全网兜底   return result; };

完整数据流如下：

存储 / 编辑器：  "${adInfo.app.title}"   ← DSL 规范格式，不变         ↓ 后端 VAST 下发时 replace(/\$\{/g, 'JHs=') VAST HTML：     "JHs=adInfo.app.title}"  ← AppLovin 不识别，忽略         ↓ 渲染引擎 parseAdContext → JSON.parse filter.ts 输入： "JHs=adInfo.app.title}"         ↓ decodeVastEscape：JHs= → ${         ↓ replaceDollarExpr 求值 渲染输出：      "My App"                 ← 正确值

DSL 存储格式不变，编辑器不用改，存量数据库里的 DSL 不需要迁移，plugin/ 下所有组件的默认值不用动。这次改动本项目只涉及两个文件：filter.ts 和 utils.ts。

这里提一下 utils.ts 为什么也要改。渲染引擎的模板求值链路里有一个性能优化：如果字符串不包含 ${，则判定不存在模板表达式，直接返回原值，跳过 filter 的求值流程。引入 JHs= 转义后，含转义的字符串不再包含 ${，会被这个快速路径错误短路——字符串原样上屏，JHs=adInfo.app.title} 直接展示给用户。因此需要在 utils.ts 的快速路径判断条件里同步加入对 JHs= 的检测，确保含转义的字符串能正常进入 filter 完成 decode + 求值。

代价和风险

这个方案不是没有代价，要诚实说清楚。

风险一：DSL 字符串里恰好自然出现 JHs=

概率极低——需要四个特定字符 J、H、s、= 恰好相邻。一旦出现，这四个字符会被误还原为 ${，渲染引擎的 resolveExpression 求值失败后会 catch 并返回空串。行为上和当前 AppLovin 宏替换破坏的结果一致，不会引入新的错误类型，只是在这个极低概率的 edge case 下会"误伤"一个无关字符串。

风险二：后端多处注入点漏改

如果后端有不止一处把 DSL JSON 注入 VAST HTML，遗漏的注入点仍走旧路径，AppLovin 渠道依然有损。filter.ts 的 replaceBareExpr 兜底对简单 identifier path 仍部分有效，但不能作为依赖。这是工程纪律问题，需要后端侧做完整排查。

广告链路里的"隐形房客"

这个 Bug 说到底，是广告投放链路上"隐形房客"问题的一个典型样本。

VAST 宏替换是一个合法的协议功能，AppLovin 这么做没有任何错——它在做它应该做的事。我们的 DSL 用 ${expr} 语法也没有任何错——这是模板引擎的标准写法。问题在于，DSL 这个"租户"需要穿越 VAST 这个"建筑"，而建筑的管理规则和租户的行李恰好产生了冲突。

在商业广告里，这类"三方协议撞车"并不罕见：Tracking URL 里的动态参数、各家 DSP 各自的宏格式、中间层 ad exchange 的二次处理……每一层都有自己的解析逻辑，每一层都可能把上一层精心构造的数据当成"可处理内容"给动一刀。

对这类问题，"解法方向"往往就是找到那个层与层之间的透明通道——让你的数据在不该被碰的地方，看起来不像任何人想碰的东西。JHs= 就是这条透明通道的化妆品。

ps：JHs= 这个值是 btoa('${') 的固定计算结果，在不同引擎、不同环境中均为同一值，可放心作为常量使用——但如果哪天有人真的在 DSL 字符串里手打了这四个字符，记得回来看一眼这篇文章。