他们说华为智驾里程造假，我花了十分钟查了查代码

他们说华为智驾里程造假我花了十分钟查了查代码有人在抖音发了条视频讽刺华为意思是说华为官网那个安全里程数据是造假的。理由是断网了还在涨。他打开飞行模式手机屏幕录屏但页面上的累计驾驶里程数字还在滚动。很多观众认为是纯前端脚本骗人的东西。语气里带着一种「又让我逮着一个」的兴奋。这条视频有多少人看过我不知道但转发的、骂的、跟着嘲讽的不少。华为嘛流量密码。往坏处说总能吃到点赞。但我是真的被勾起了好奇心——或者说被勾起了职业病。我干过前端我知道要验证一个计数器是真是假最直接的办法就是打开开发者工具看 Network 面板。于是我打开了华为那个页面。https://auto.huawei.com/cn/ads/safety-and-data-report页面上三个大数字乾崑智驾累计辅助驾驶里程、搭载乾崑智驾车辆累计行驶总里程、累计主动避免可能的碰撞。数字在滚动看起来确实很「大厂数据看板」。F12 打开Network 一栏。很快就看到有一个接口在规律地轮询。auto.huawei.com/external/uiapi/ads/v1/query每3秒一次。返回的数据结构很干净三个字段分别对应页面上三个计数器。这是正经的后端 API。不是本地模拟不是Mock数据是从华为车云平台拿回来的真实聚合值。怎么判断的我盯了一会儿数据的变化。相邻两次请求之间里程的增长量不是恒定的。不同时段取了几组样本增速波动大约有26%。一个匀速定时器是不可能产生这种波动特征的。只有真实的车辆遥测数据聚合才会在不同时段有不一样的增速——早晚高峰跑得多凌晨跑得少很合理。但那个视频里的「断网还在涨」是怎么回事我开始查页面加载的 JavaScript 文件。在 Sources 面板里扫了一圈有一个文件的名字让我眼皮跳了一下。safety_kilometer.js打开。好家伙。里面躺着一组硬编码的数字初始值7,228,242,208基准时间2026-01-12固定增速224.86 每秒完完全全的纯前端定时器。拿当前时间减去基准时间乘以固定增速加上初始值算出「当前里程」。跟后端没有任何关系。如果你只看这个文件你会觉得——实锤了。华为就是拿一个定时器在页面上跑假数据。但我多看了一眼。这个 JS 操作的目标 DOM 是#ias-gongli和#ias-pengz。在当前页面上这两个 ID 的元素根本不存在。搜索了整个 DOM没有。那这个文件是怎么被触发的我看了一下调用链。它在页面加载时执行会去找那两个元素找不到就什么都不做——没有报错没有降级什么都没有。安安静静地躺着。但我注意到一个细节。页面上有个二维码引导去「华为乾崑 APP」。我猜这个文件根本不是给官网用的。对比一下 safety_260521.js 和 safety_kilometer.js 就知道它们完全是两套思路safety_260521.js 依赖 jQuery Web Worker AJAX数据走 API 轮询有复杂的滚动动画打包完 28KB。是个正经的官网方案。而 safety_kilometer.js 呢纯原生 JS零依赖直接在内存里算数然后改 innerHTML解码后连 1KB 都不到。最合理的猜测这个文件是给华为乾崑 APP 里的 H5 内嵌页准备的。APP 内嵌页需要秒开不能等 jQuery 加载完再等 API 返回所以用纯原生 JS 加一组硬编码初始值跑一个「离线可用」的计数器。等网络就绪之后再通过 APP 的 JS Bridge 拿到真实数据做修正。官网和 APP 内嵌页共用同一套 CDN 静态资源。所以这个文件就跟着部署到了官网的服务器上但官网的 HTML 里没有对应的 ID 元素它就安安静静地躺着什么都不做。不是什么阴谋。就是两个端共用一套资源条件加载没做干净而已。这种事情在正经公司的前端项目里太常见了。所以表象开始分裂了有真实的 API 在驱动前台数字。也有一个硬编码的定时器文件躺在服务器上。但它压根就不是给这个页面用的。那「断网还在更新」到底是什么在更新我模拟了一下断网场景。手机开热点连上刷新页面等一次 API 成功之后关掉热点。有意思的事情来了。计数器没有马上停下。它确实还在动。但仔细看它动的状态跟正常联网时不一样。正常联网时数字的滚动是平滑的、持续的每隔 3 秒有个微小的跃迁。断网之后数字变成在一个小范围内来回震荡幅度越来越小大概 12 秒左右彻底停住。我又去翻了代码。逻辑是这样的主循环每 3 秒发一次 AJAX 请求到那个后端 API。请求正常 → 更新目标值 → Web Worker 做 4 秒的滚动动画从当前值「跑」到最新值。请求失败 → error 回调触发。断网之后发生了什么第 0 秒AJAX 成功拿到值启动 4 秒动画。第 3 秒新的 AJAX 发出失败。error 回调启动重新从当前值上一次动画跑到一半的位置往最后一次成功的 API 值做 4 秒动画。第 6 秒新的 AJAX 再次失败。同样的流程再来一次。每一次 error 回调都会重新开始动画。但每次重新开始的时候当前值都比上一次更接近目标值因为上一次的 3 秒动画已经把数字往前推了一段。所以「新的动画」能跑的幅度越来越小。不断重启不断衰减。大概 4 到 5 轮之后当前值几乎等于目标值动画的视觉幅度小到肉眼无法分辨。12 秒收敛。这就是全部的真相。它不是「断网了还在更新」。它是 AJAX 失败的 error 回调在不甘心地一遍遍重试每一次都让动画从当前位置再「追」一次目标值。动画越追越近直到追平归零。是动画的缓出残留不是计数器的灵魂出窍。用一个更形象的比喻就是你推了一把秋千秋千开始荡。断网之后没人再推了但秋千还会继续荡几轮幅度越来越小最后停下来——然后那个拍视频的人说「你看没人推了还在荡这秋千是假的。」秋千确实还在荡。但和造假是两回事。说回那个视频。我后来专门去看了一下那条抖音的评论区。没有有一个人去查证呃都是在一边倒的骂华为。没有一个人跑去打开那个页面看一眼。没有一个人打开F12看一看Network面板。没有一个人问一句「断网还在更新到底是真的在更新还是动画没停住」全部在一边倒地骂。我有时候觉得这可能才是整件事里最值得想一想的。华为这个设计有问题吗说实话我觉得没有。请求失败的时候保留最后一次拿到的值继续做平滑动画让数字缓缓停住——这太正常了。你要是请求一失败数字就卡在那不动了用户反而会觉得页面崩了。把最后一次的值安安稳稳地展示完缓出停住反而是合理的体验设计。真正的差别在于正常人看到「断网了数字还在动一小会儿然后缓缓停住」不会觉得有什么问题。但那个视频选择只截取了「还在动」的那一段没给大家看它停下来的样子。那个视频的叙事为什么传得这么快。因为它太「好懂」了。断网数字还在动造假。三步。任何一个刷到的人都能在几秒内消化全部剧情同时收获一份智商上的优越感——这种感觉是会上瘾的。而真相呢。真相需要你打开DevTools看Network面板看Sources面板看代码逻辑理解WebWorker动画理解缓出函数。需要花时间。需要一些耐心。一个几秒就能消化的「黑幕」和一个至少也得十分钟才能搞懂的「真相」在传播速度上后者没有任何胜算。我不是在指责谁。我自己也是这样的。刷到那个视频的时候我的第一反应也是「嗯好像确实有点问题」。但区别可能仅仅在于我恰好干过前端恰好知道怎么打开开发者工具恰好有十来二十分钟可以拿来折腾这件事。如果我不具备这些条件呢。我可能也会转发那条视频配一句「华为就喜欢搞这些虚的」。所以我在想的问题是——我们到底是在「求真」还是在「求认同」那个视频的评论区里没有人是在「求真」的。所有人都是在「求认同」。求一个「看吧华为果然不行」的认同。求一个「我又看穿了一个骗局」的认同。这种认同来得太容易了不需要你付出任何成本只需要点一个赞或者转发一下。而「求真」是需要成本的。需要你花时间需要你动手需要你承认自己可能错了。我们生活在一个信息传播速度远超信息验证速度的时代。一个十几秒的抖音视频可以在半天内被几十万人看到但真正去打开那个页面看一眼的人我猜可能连一百个都不到。写这些不是为了给华为洗地。华为不需要我帮它洗地。那个 safety_kilometer.js 确实是一个官网用不上的文件它是给 APP 内嵌页准备的。两个端共用一套 CDN 资源条件加载没做干净算不上什么罪过。我只是觉得如果下一次再刷到类似的「揭露黑幕」的视频也许可以在转发之前先花三秒钟问自己一句他说的这个现象有没有其他可能的解释那个计数器不是假的。那个「断网还在更新」的现象也不是什么阴谋。就是一个很普通的动画缓出设计请求失败时保留最后一次值平滑停住仅此而已。我觉得这个故事的真正价值不在于判断华为的对错。在于它让我们看到一个「看起来像是造假」的现象和一个「实际是造假」的现象中间的差距可以有多大。也在于它让我们看到在信息爆炸的年代一个十几秒的视频可以轻松覆盖几十万人但真正去验证它的人可能连一百个都不到。下次再看到这种「揭露黑幕」的内容时也许可以多问一句——真的是这样吗。以上既然看到这里了如果觉得不错随手点个赞、在看、转发三连吧如果想第一时间收到推送也可以给我个星标⭐谢谢你看完下次再见。