文 | 静静

5月26日傍晚，正是城市一天中最拥堵、也最依赖即时出行系统的时段，滴滴再次把大量用户晾在了路边。

公开报道显示，滴滴此次的异常集中在行程管理和支付环节，部分用户端出现无法开启行程、定位异常，司机端则出现接单后无法结束订单，甚至无法取消订单等情况；当日18时许，在线客服和客服电话也一度无法正常接入人工客服。

晚间，滴滴回应称，因云厂商网络专线故障，造成5月26日17点左右滴滴App部分服务出现短暂故障，服务已全部恢复，并称将处理故障期间产生的费用异常问题。

（图片来自滴滴出行官方微博）

如果这只是一次偶然事故，可以被当作是偶发宕机。

但滴滴的问题恰恰在于，它不是第一次崩，也不是第一次在晚高峰、订单链路、支付结算、客服响应这些关键环节上露出脆弱性。2023年11月27日，滴滴也曾出现大范围服务异常，后续公布的初步调查结果称，事故是因为底层系统软件发生故障；那次故障影响了网约车、骑行、代驾等多项业务，用户同样遭遇无法定位、无法下单、订单无法结束等问题。

滴滴今天仍然会崩，表面看是云专线、底层软件、机房网络、系统升级这些技术名词轮番登场，深处看则是出行平台规模扩张之后，其基础设施的不确定性，因为出行关乎着乘客行程安全的兜底，以及司机劳动报酬的确认。

本文试图解析，这一次故障到底暴露了什么；反复崩溃背后的架构性原因是什么；以及滴滴这家公司的资源到底投向了哪里。

01 为什么今天滴滴还会崩？

滴滴给出的致歉很简洁，第一句话说明原因，是云厂商网络专线故障。第二句话则表明费用异常正在处理。对于一次让大量用户在晚高峰困在路边的系统崩溃，这个交代过于简洁了。

先看故障的实际影响范围。据澎湃新闻综合用户反馈，受影响的区域包括广东、江苏、北京、江西、新疆等多个省份，问题不是简单的App打不开，而是无法开启行程、司机接单后无法结束订单、无法取消订单、定位飘忽，客服电话和在线客服均无法接通。这意味着，一个外部网络链路的故障，击穿了滴滴从前端交互到后端结算的整条业务链。

（图片来自小红书）

在任何一个合格的分布式系统架构中，外部链路故障属于最常见、最应被提前设防的风险类型。标准做法是部署多路冗余链路，在单一链路中断时自动无感切换到备用链路。理论上，用户甚至不应该感知到切换发生过。但滴滴的情况是，一条专线故障就让全国核心业务异常了近两个小时。

这暴露出两个问题。第一、滴滴的链路设计可能存在单点依赖。也就是说，虽然名义上部署了多机房、多活架构，但在某些关键链路上，仍然依赖单一的物理通道，一旦这条通道出问题，整个系统就被打穿。

第二、滴滴的降级预案缺失。在主服务不可用时，平台是否具备离线模式、短信叫车或简化版应急入口？至少从用户侧反馈看，滴滴没有展现出足够清晰、可用、独立于主App的应急入口。

这不是滴滴第一次被同样的问题绊倒。2023年11月那场持续12小时的事故，滴滴官方给出的结论同样是底层系统软件发生故障。

两次底层故障，间隔不到三年。这说明一个问题：2023年那场事故之后，滴滴在系统稳定性和能力上的投入，并没有带来质的改变。

（图片来自滴滴出行官方微信公众号）

而用户在故障中的处境，每次都是相同的。App打不开，客服联系不上，行程状态不可知。而真正的应急体系应该有一条独立于主系统的备用通道，哪怕只是一个最简单的热线电话，确保用户在平台瘫痪时还能联系到真人。

这条路，滴滴至今没有修通。

02 反复崩溃背后，是技术投入不够

一次故障可以解释为偶发，但一而再再而三，就不能再用巧合来解释。

翻看滴滴历次故障原因，会发现一个规律性的表述。2015年，深圳部分服务器遭遇技术故障。2016年，全系统崩溃。2019年，系统更新时出现故障导致导航出现问题。2021年，出现打不了车、行程看不见、司机无法结束订单等多种异常。2022年，机房网络故障。2023年11月，底层系统软件发生故障。2025年，同样是底层系统软件问题。2026年，云厂商网络专线故障。

表面上看，每次故障的直接原因各不相同。但仔细分析，它们指向的是同一个深层问题：滴滴的系统架构始终没有建立起足够的韧性来应对各类异常。

一个成熟的分布式系统，应该具备几个关键能力。一是故障隔离，不同业务模块之间的异常应该隔离。但2023年的事故证明，滴滴的网约车、共享单车、内部系统同时瘫痪，隔离形同虚设。

二是容灾切换，主系统出问题时备用系统应该在秒级完成接管，但这些技术上的设计在真正的故障场景中似乎失效了。

一家头部出行平台，为何会在这些基本功上出问题？

（图片来自滴滴出行官方微信公众号）

这跟滴滴近年来的技术投入策略有直接关系。

一个被反复提及但很少被深挖的是滴滴云的战略收缩。滴滴在2017年上线了自有公有云滴滴云，初衷是把核心基础设施掌握在自己手中。但这条路没有走通。2023年3月31日，滴滴云正式宣布停止对外提供公有云服务。

从技术上讲，公有云厂商的容灾体系和运维经验是单个企业短期内无法复制的。公有云厂商在多地部署、链路冗余、故障切换方面的投入是千亿级别的。一个企业的私有云环境，可能无法与公有云厂商的规模效应抗衡。

与此同时，从滴滴往年的财报表现不难看出，其研发费用正在不断缩减。2023年三季度开始，在营收增长的情况下，滴滴的运营和销售费用均同比增长，唯有研发投入连续多个季度下滑。

到了2024年第二季度，研发费用下降到18亿元，同比下降了17.3%。2025年全年，研发费用84.4亿元，同比增长8.8%，看似恢复了增长，但同期销售及营销费用暴增至319.1亿元，同比增长56.6%。

与此同时，滴滴的人员规模也在收缩。有数据显示，公司员工数量从2.44万人缩减至1.91万人，截至2025年12月31日员工总数回升至22335人，但对比业务规模的增长，技术团队的负荷只会更重。

几重因素叠加在一起，构成了滴滴系统频繁崩溃的结构性根源。

03 滴滴的钱花在哪里了？

如果只看财务数据，滴滴是一家体量庞大、正努力赚钱的公司。2025年全年总营收2267亿元，同比增长约10%。其中，中国出行业务贡献了2019亿元的收入，经调整EBITA为123.5亿元，这是一笔可观的利润。但问题不在收入端，而在支出端。

（图片来自滴滴财报）

财报显示，2025年滴滴国际业务经调整EBITA亏损60.5亿元，创新业务亏损26.3亿元，两个板块加起来亏了大约87亿元。国内出行赚到的123.5亿利润，有超过七成被海外和其它创新业务对冲掉。

到了第四季度，情况更严峻：中国出行赚了26亿元，国际业务亏了34亿元，创新业务亏了13亿元。海外一个季度亏的钱，已经超过了国内整个季度的利润。

再看钱的流向。滴滴2025年四季度及全年业绩公告显示，2025年全年营收为2267亿元，同比增长9.6%；研发费用为84亿元左右，同比增长8.8%；销售及营销费用是168亿元左右，同比增长46.1%。两者增速相差较大，新增营销开支明显高于新增研发开支。

这种投入结构反映的是战略重心。滴滴CEO程维的路径很清晰，用国内业务产生的现金流，去博海外市场的增长。巴西和墨西哥的外卖大战、自动驾驶的持续投入，都需要大量资金。这些投入方向本身没有对错之分，但当一个企业把绝大部分新增资源投向市场扩张，留给系统稳定性和安全基础设施的预算必然被压缩。

还有一个不容忽视的层面，安全。2023年11月故障中，滴滴的系统崩溃不仅影响了打车和支付，连内部安全运维系统也同步瘫痪。这意味着，在故障持续的十多个小时里，行程轨迹无法追踪，紧急联系人无法获取实时信息，一键报警等功能可能无法使用。平台在事故发生时，自身也丧失了保障用户安全的能力。

《网络安全法》对运营者提出明确要求：应当采取技术措施和其他必要措施，保障网络安全、稳定运行，有效应对网络安全事件。《网络预约出租汽车经营服务管理暂行办法》也要求平台落实安全防范措施，提高抗风险能力。法律条文不是摆设，但对一个习惯于在故障后道歉然后翻篇的平台来说，这些规定的约束力似乎不够强。

如今，服务恢复了，致歉发布了，热搜也会慢慢退去。但这件事不应该就这么过去。

作为一个日均数千万订单、承载数亿用户出行的平台，滴滴已经不仅仅是一家商业公司，它承担着一定的公共职能。这种职能要求它在扩张和盈利的同时，把系统的可靠性放在一个足够高的优先级上。

下一次故障什么时候来，没有人知道。但如果滴滴的基本功还没打好，那么下一次用户的等待，还会和这次一样漫长。

       原文标题 : 滴滴又崩了，出行巨头的护城河为何越修越浅？