有些用户明明设置了"仅Wi-Fi下载"，手机流量却在几天内被Audible吃掉17GB。这不是误操作，是版本26.19.13的代码bug在后台反复拉取数据。

PiunikaWeb收集的多起投诉显示，数据消耗规模差异很大，但共同点是用户都开启了"仅限Wi-Fi"的省流量开关。一位用户贴出的客服对话揭示原因：云同步和许可证验证环节出现故障，导致应用无法识别本地已下载的有声书，于是不断通过移动网络重复下载。

打开网易新闻 查看精彩图片

另一份客服记录更具体——支持人员承认该版本"绕过了内部的'仅Wi-Fi'开关"，即便书籍已存储在本地，后台仍持续流传输数据。这意味着用户的流量设置被代码逻辑直接无视。

打开网易新闻 查看精彩图片

Audible方面确认已知悉问题，但未给出修复时间表。对受影响用户，临时方案是进入安卓系统设置，在Audible的"应用信息"中找到"移动数据使用"，关闭"后台数据"开关。这能阻止应用在后台联网，但无法解决前台使用时的异常消耗。

这个bug的隐蔽性在于：用户很难第一时间发现。安卓系统的流量统计通常按月重置，等收到运营商账单或流量告警时，损失已经造成。对于依赖移动数据通勤听书的用户，这种"静默消耗"尤其致命。

打开网易新闻 查看精彩图片

值得追问的是，一个许可证验证模块为何能触发如此大规模的数据传输？从客服描述看，问题出在"无法识别本地文件"→"触发重新下载"→"仍无法识别"的循环死结。这种设计缺陷暴露了一个常见的产品盲区：离线功能的前端体验做得再流畅，如果后台同步逻辑有漏洞，反而会成为用户的成本黑洞。