一张神图揭秘：全球数字基础设施的脆弱真相你的手机App、ChatGPT、抖音，全都建在一堆危房上面深度解读 · 附TLDR速查表 · SOP自检清单
🏗️ 一张神图揭秘：全球数字基础设施的脆弱真相
你的手机App、ChatGPT、抖音，全都建在一堆危房上面
深度解读 · 附TLDR速查表 · SOP自检清单
📋 TLDR 速查表（30秒看完核心）
ASML · 全球唯一能造EUV光刻机的公司，100%垄断，没有它就没有先进芯片
Excel · 160亿美元医疗系统用它管财务，JP摩根因它亏了60亿美元
开源维护者 · 全球关键基础设施依赖约1万名没拿工资的志愿者
Log4j事件 · 16名无薪志愿者维护的库，漏洞让数十亿台设备暴露风险
底层真相 · 你用的所有科技产品，底层全是单点故障在支撑
最近网上疯传一张图，画的是「全球数字基础设施」的真实架构——从你刷的短视频到AI大模型，所有东西都建在一座摇摇欲坠的「技术巴别塔」上。
最骚的是：塔底竟然是一个Excel表格。
你以为这是玩笑？不，这是残酷的真相。
✦ ✦ ✦
一 先来看懂这张「科技圣经」级神图
这张图把整个数字世界画成了一座「叠叠乐」塔，从下往上依次是：
🏛️ 从底层到顶层的「科技食物链」
地基 Excel · 没错，就是你用来做表格的那个玩意儿
L1 ASML · 全球唯一能造顶级光刻机的荷兰公司
L2 Intel / AMD / NVIDIA · 芯片设计和制造
L3 硬件厂商 · Framework、苹果、联想、戴尔、惠普
L4 Linux Foundation · 操作系统的根基
L5 DNS + AWS + Cloudflare · 网络基础设施
L6 无薪开源开发者 · 全球基础设施的隐形英雄
L7 AI + V8 + WASM · 应用层和Web技术
顶层 "网上发生的各种事" · 也就是你刷的抖音、用的ChatGPT
图里还有几个神来之笔：
✦ 愤怒的小鸟指向「微软在干的事」——讽刺微软总是莫名其妙搞事情
✦ 有个人在用尺子量鲨鱼——据说是梗图「萨达姆·侯赛因」，暗示某些依赖同样不可预测
✦ 整座塔的标题是「ALL MODERN DIGITAL INFRASTRUCTURE」——所有现代数字基础设施
"The security of the global Internet depends on countless obscure pieces of software written and maintained by even more obscure unpaid, distractible, and sometimes vulnerable volunteers."
「全球互联网的安全，取决于无数不起眼的软件，而这些软件是由更不起眼的、无薪的、容易分心的、有时还很脆弱的志愿者写和维护的。」
✦ ✦ ✦
二 ASML：比石油垄断还可怕的「沉默垄断者」
🔬 它到底是干啥的？
简单说：ASML是全球唯一能造顶级光刻机的公司。
打个比方：如果芯片是「数字时代的石油」，那ASML就是「唯一的炼油厂设备制造商」。没有它的机器，台积电、三星、英特尔全都只能干瞪眼。
💥 触目惊心的垄断数据
1EUV光刻机市场份额：100%（完全垄断）
2整体光刻机市场份额：94%（2024年数据）
3一台EUV机器的价格：3.8亿美元（约27亿人民币）
4机器重量：180吨，由10万+个零件组成
5研发时间：30年，投入超90亿美元
对比一下：OPEC控制全球40%的石油产量，已经让全世界头疼了。而ASML在最先进芯片制造设备上的垄断是100%。
🤯 为什么只有它能造？
EUV光刻机的技术难度有多变态？让我用大白话解释：
✦ 光源：需要用激光每秒打5万次锡滴，产生极紫外光——这种光在地球大气里根本不存在，只存在于外太空
✦ 镜面精度：反射镜的平整度要求达到原子级别——蔡司花了15年才做出来
✦ 工作环境：整个系统必须在真空中运行，因为EUV光会被空气吸收
✦ 供应链：全球5150+家供应商参与，ASML自己只生产15%的零件
"ASML is the beginning of the tech hardware supply chain. The entire tech ecosystem relies on ASML."
「ASML是科技硬件供应链的起点。整个科技生态系统都依赖ASML。」
更恐怖的是：中国正在秘密研发自己的EUV机器。2025年初，一个神秘项目在深圳完成了原型机测试，据说能产生EUV光了，但距离量产芯片还有好几年。华为在幕后协调，数千名工程师参与，被形容为「中国版曼哈顿计划」。
⚠️ 单点故障警告：如果ASML的荷兰工厂出了任何问题，全球先进芯片生产立刻停摆——你的iPhone 20、英伟达显卡、最新AI服务器，全部凉凉。
✦ ✦ ✦
三 Excel：整个数字世界的「最后一根稻草」
图里最骚的操作是：整座技术巴别塔的最底层是一个Excel表格。
你可能觉得这是程序员的黑色幽默。但让我告诉你几个真实发生的灾难：
💥 案例一：JP摩根「伦敦鲸」事件 —— 亏损60亿美元
2012年，JP摩根的一个交易员因为Excel复制粘贴错误，导致风险模型算错。
具体错误：本该用「平均值」的地方用了「求和」。
结果：62亿美元打水漂，CEO年薪从2300万砍到1150万，罚款9.2亿美元。
💥 案例二：英国新冠数据丢失 —— 1.6万病例「人间蒸发」
2020年10月，英国公共卫生部门用Excel汇总新冠检测数据。
问题：他们用的是老版本.xls格式，最多只能存65000行。
结果：近16000例确诊病例没被记录，接触追踪全面延误。
💥 案例三：新西兰160亿医疗系统 —— 用Excel管财务
2025年曝光：新西兰价值280亿纽币（约160亿美元）的公共医疗系统，财务管理的核心工具是……一个Excel表格。
审计报告指出：数据经常是「硬编码」的，错误不会被发现，月度财务报告需要12-15天才能汇总完成。
他们还运行着6000个应用程序和100个数字网络——平均每450个员工就有一套系统。
"Nearly 90% of Excel spreadsheets contain errors. In a hospital, even a single wrong entry could wrongly mark a critical device as available."
「近90%的Excel表格包含错误。在医院里，哪怕一个错误条目都可能把关键设备标记为可用。」
所以图里把Excel放在最底层，不是开玩笑——全世界有太多关键基础设施真的在用Excel，而且88%的表格都有错误。
✦ ✦ ✦
四 无薪开源开发者：扛着整个互联网的「隐形巨人」
图里有一层写着「UNPAID OPENSOURCE DEVELOPERS」（无薪开源开发者）。
这不是玩笑。让我告诉你几个细思极恐的事实：
📊 2024年开源维护者调查数据
60% 的开源维护者没有拿到任何报酬
61% 的无薪维护者是独自一人在维护项目
48% 的维护者感到不被重视、没人感谢
全球80%的开源软件使用量由约1万人在支撑
😱 Log4j事件：16个志愿者 vs 数十亿台设备
2021年12月，一个名为Log4j的Java日志库爆出史诗级漏洞，影响了从iCloud到Twitter的无数系统。
这个被全球无数企业依赖的关键库，是由谁维护的？
🔥 触目惊心的真相
维护团队：Apache基金会下的16名无薪志愿者
漏洞爆发时，项目负责人Ralph Goers只有3个小赞助商
另一位核心开发者Volkan Yazici说他那几周每天工作22小时——全是无偿的
美国网络安全局局长称这是她见过的「最严重的漏洞之一」
"There is this culture of taking from open source without giving anything back. It is like the problems of the people who make the dependencies are irrelevant."
「有一种文化是只从开源索取而不回馈。好像创造这些依赖的人遇到的问题根本无关紧要。」
🕵️ xz后门事件：差点毁掉整个互联网的「卧底」
2024年，一个更恐怖的故事被揭露：
2021年
一个叫「Jia Tan」的账号开始给xz Utils项目贡献代码
2022年
项目原维护者Lasse Collin因长期心理健康问题和burnout，公开表示「我的关心能力已经相当有限」
2023年
「Jia Tan」成功获得项目控制权，开始慢慢植入后门代码
2024年3月
后门几乎要进入所有主流Linux发行版——一旦成功，全球数百万服务器将门户大开
2024年3月29日
一位微软员工Andres Freund在业余时间发现了异常，及时阻止了灾难
⚠️ 细思极恐：这是一次国家级别的长期渗透行动，攻击者花了3年时间取得信任。而我们的关键基础设施，就这样依赖着一个精疲力竭的志愿者。
✦ ✦ ✦
五 图里其他层的「骚话」解读
🌐 DNS：互联网的「电话簿」
你输入baidu.com，DNS把它翻译成IP地址。如果DNS崩了，你连百度都打不开——不是百度的问题，是你根本找不到它在哪。
☁️ AWS / Cloudflare：云端的「房东」
全球大量网站跑在AWS和Cloudflare上。2017年AWS S3故障4小时，整个互联网都在颤抖——Slack、Trello、Imgur全部躺平。
🐧 Linux Foundation：操作系统的「祖师爷」
全球96%的服务器跑Linux，你的安卓手机底层也是Linux。这个系统主要靠志愿者和企业捐赠维护。
😠 愤怒的小鸟指向「微软在干的事」
程序员圈的老梗——微软经常搞一些莫名其妙的更新，比如Windows Update在你演讲时强制重启、把你的浏览器默认设成Edge、在开始菜单塞广告……
🤖 AI / V8 / WASM：应用层
V8是Chrome的JavaScript引擎，WASM是网页里跑高性能代码的技术，AI就不用解释了——这些是你能看到的「光鲜表面」，但底下全是上面那些摇摇欲坠的依赖。
✦ ✦ ✦
六 这张图给我们的启示
💡 对普通人的启示
1你用的任何数字服务都可能突然崩溃——做好备份
2别把所有鸡蛋放在一个云服务里
3如果你用开源软件，考虑给维护者捐点钱
💼 对企业的启示
1审计你的软件供应链——你可能依赖着一个burnout的志愿者
2别用Excel管关键业务数据——真的会出事
3给你依赖的开源项目付费或派人贡献代码
🌏 对国家的启示
1关键技术不能有单点故障——ASML的垄断就是活生生的例子
2开源基础设施需要国家级的支持和资金
3供应链安全不只是芯片，软件同样重要
"We need some sustainable ways to fund open-source projects that become de facto critical infrastructure."
「我们需要一些可持续的方式来资助那些事实上已成为关键基础设施的开源项目。」
✦ ✦ ✦
七 SOP自检清单：你的数字生活有多脆弱？
🔍 个人层面检查
□ 我的重要文件有本地备份吗？
□ 我用的云服务有几个？如果一个崩了我还能工作吗？
□ 我知道我常用App依赖哪些服务吗？
□ 我给任何开源软件捐过款吗？
🏢 企业层面检查
□ 我们的核心业务有用Excel管理的部分吗？
□ 我们知道依赖了哪些开源库吗？
□ 这些开源库的维护状态如何？有没有单人维护的？
□ 我们有SBOM（软件物料清单）吗？
□ 我们给关键依赖的开源项目付费或贡献代码了吗？
□ 如果AWS/阿里云崩了，我们能活多久？
🛡️ 风险意识检查
□ 我理解什么是「单点故障」吗？
□ 我知道ASML对全球芯片供应的垄断意味着什么吗？
□ 我了解Log4j和xz事件的教训吗？
□ 我有灾难恢复计划吗？
💬 你觉得这张图还漏了什么？
欢迎在评论区补充你认为被低估的「数字基础设施」依赖！
⚠️ 免责声明：本文所有信息均来自公开可查的互联网资源，仅供参考和学习交流目的。数据和案例可能随时间变化，请以官方最新信息为准。
📚 参考来源：
1. ASML官方投资者日报告 (2024年11月)
2. TrendForce半导体产业分析报告
3. JP摩根「伦敦鲸」事件官方130页调查报告
4. MIT Technology Review: The internet runs on free open-source software
5. OpenSSF Log4j事件一周年复盘报告
6. Tidelift 2024年开源维护者调查报告
7. 新西兰Health NZ财务审计报告 (Deloitte)
8. Reuters中国EUV项目独家报道
参考原文链接列表：
1. https://www.fool.com/investing/2025/12/12/asml-is-the-silent-monopoly-behind-the-entire-tech/
2. https://www.trendforce.com/insights/asml-euv
3. https://www.technologyreview.com/2021/12/17/1042692/log4j-internet-open-source-hacking/
4. https://socket.dev/blog/the-unpaid-backbone-of-open-source
5. https://securityboulevard.com/2024/04/backdoor-in-xz-utils-that-almost-happened/
6. https://www.prosperspark.com/the-6-billion-excel-error/
7. https://www.theregister.com/2025/03/10/nz_health_excel_spreadsheet/
8. https://ia.acs.org.au/article/2020/excel-causes-uk-covid-confusion.html
9. https://www.idnfinancials.com/news/59732/chinas-secret-lithography-project-challenges-asmls-monopoly
10. https://openssf.org/blog/2022/12/15/avoiding-the-next-log4shell-learning-from-the-log4j-event-one-year-later/
✨
— END —